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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3 GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 



The present document defines optional Optimal Media Routeing (OMR) procedures that can be applied by entities in 
the IP Multimedia Subsystem (IMS) that control media resources and are capable of manipulating the Session 
Description Protocol (SDP) as defined by IETF RFC 4566 [6]. 

The OMR procedures in the present specification relate to the handling of OMR-specific SDP attributes that are 
documented in TS 24.229 [4]. The OMR procedures use SDP offer/answer related procedures in IETF RFC 3264 [5] 
and in 3GPP TS 24.229 [4] in a backward-compatible manner. 

The 3GPP network architecture, including the configuration and network entities of the IMS, is defined in 3GPP TS 
23.002 [2]. The stage 2 of the IMS is defined 3GPP TS 23.228 [3]. Annex Q of 3GPP TS 23.228 [3] documents the 
architecture and call flows for OMR. 

The OMR procedures in this document are applicable to the following IMS entities that perform as an IMS-ALG or UA 
according to 3GPP TS 24.229 [4] and that control media resources: 

- an IBCF acting as an IMS-ALG; 

- a P-CSCF acting as IMS-ALG; 

- an AS acting as B2BUA and adapting IMS-ALG procedures to control an MRF; 

- an AS acting as B2BUA and adapting UA procedures to control an MRF; and 

- an MGCF acting as UA. 

NOTE 1: An AS acting as B2BUA to perform application functions such as conferencing or announcements will 
normally perform separate originating and terminating UA procedures, treating the media resource as an 
endpoint. An AS acting as B2BUA offering transcoding options will typically follow IMS-ALG 
procedures. 

NOTE 2: The controlled media resource can be a TrGW, IMS-AGW, MRF, or a media function of the entity 
performing OMR. 

The OMR procedures are not applicable for an UE. 
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3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1], and the following 
apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 3 GPP 
TR 21.905 [1]. 

Codec: A media configuration for a media line in SDP that is specified by one or more formats in the format list of the 
m-line, by one or more preferred configurations (pcfg) associated with the media line, or by a combination of both. 

Codec Change: Any modification to the media configurations for the media line in the format list or the list of 
preferred configurations. 

Codec List: Either the format list of the m-line, or a combination of all the preferred configurations and the format list 
for the media line. 
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Incoming termination: The termination at an MR in the direction from where an incoming SDP offer is being received 
at the IMS-ALG that is controlHng the MR. 

IP realm: A collection of IP endpoints identified by a unique name, where all IP endpoints are mutually reachable by 
means of IP routeing. 

Media resource: An IMS Network entity that provides resources to process media streams and is controlled by an 
entity applying OMR procedures. A TrGW, BGW, MRF, or a function internal to the entity performing OMR can be a 
media resource. 

Outgoing termination: The termination at an MR in the direction towards where an outgoing SDP offer is being sent 
at the IMS-ALG that is controlling the MR. 

3.2 Symbols 

For the purposes of the present document, the following symbols apply: 

Ix Reference Point between IBCF and TrGW 

Iq Reference Point between the P-CSCF and the IMS Access Gateway 

3.3 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1], in 3GPP TS 23.228 [3] and 
the following apply. An abbreviation defined in the present document takes precedence over the definition of the same 
abbreviation, if any, in 3GPP TR 21.905 [1] or in 3GPP TS 23.228 [3]. 

ALG Application Level Gateway 

B2BUA Back-to-Back User Agent 

ICE Interactive Connectivity Establishment 

MR Media Resource 

OMR Optimal Media Routeing 

UA User Agent 



General 



The procedures in clause 5, clause 6 and clause 7 shall apply separately to each media line with non-zero port value in 
each SDP message, and shall apply separately to each SDP offer/answer transaction. In the presence of forking of a SIP 
INVITE request that includes an SDP offer, the OMR procedures for handling of the SDP offer apply once for all 
forked dialogs, and the OMR procedures for handling of the corresponding SDP answer apply independently to each 
dialog. Entities supporting OMR use the OMR-specific SDP extension attributes defined in 3GPP TS 24.229 [4]. 

OMR builds on the ALG NAT traversal model and is not consistent with ICE. 

OMR does not modify the SIP signalling route path and usually does not modify the flow of SIP messages except in 
some cases when transcoding options are offered. 



5 Common SDP Procedures 

5.1 General 

The IMS-ALG or UA using the OMR procedures in clause 6 or clause 7, respectively, shall additionally use the 
procedures in this subclause when manipulating SDP. 
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5.2 Encapsulation of previous SDP information 

5.2.1 Media level information 

If an IMS-ALG forwards an SDP offer and for a given media line: 

- adds or removes offered format(s); 

- modifies the transport protocol; 

- adds or removes other corresponding media level SDP attribute(s) than "visited-realm", "secondary-realm", "omr- 
codecs", "omr-m-att", "omr-s-att", "omr-m-bw", "omr-s-bw", "omr-s-cksum" or "omr-m-cksum" attributes; 

- modifies the value of other corresponding media level SDP attribute(s) than "visited-realm", "secondary-realm", 
"omr-codecs", "omr-m-att", "omr-s-att", "omr-m-bw", "omr-s-bw", "omr-s-cksum" or "omr-m-cksum" attributes; 

- adds or removes corresponding media level SDP bandwidth line(s); or 

- modifies the value of corresponding media level SDP bandwidth line(s), 

then the IMS-ALG shall apply the procedures below to encapsulate all media level information of the corresponding 
media line. 

The IMS ALG shall encapsulate the received transport protocol and format list of the corresponding media line within 
an "omr-codecs" attribute and add this attribute as a media level attribute for the corresponding media line. 

The IMS ALG shall encapsulate each received attribute of the corresponding media line within an "omr-m-att" attribute 
and add this attribute as a media level attribute for the corresponding media line. 

The IMS ALG shall encapsulate each received bandwidth line of the corresponding media line within an "omr-m-bw" 
attribute and add this attribute as media level attribute for the corresponding media line. 

If the IMS-ALG received any visited-realm instances in the SDP offer, the IMS-ALG shall supply the instance number 
one above the highest instance number in the received SDP offer as instance number within the "omr-codecs", the "omr- 
m-att" and "omr-m-bw" attribute(s). Otherwise the IMS-ALG shall supply the instance number 2. 

5.2.2 Session level information 

If an IMS-ALG forwards an SDP offer and: 

- encapsulated any media level information according to the conditions in subclause 5.2.1; 

- adds or removes any session level SDP attribute(s); 

- modifies the value of any session level SDP attribute(s); 
adds or removes session level SDP bandwidth line(s); or 

- modifies the value of session level SDP bandwidth line(s), 

then the IMS-ALG shall apply the procedures below to encapsulate all session level information. 

The IMS ALG shall encapsulate each received session-level attribute within an "omr-s-att" attribute and add this 
attribute as a media level attribute for every media line. 

The IMS ALG shall encapsulate each received session-level bandwidth line within an "omr-s-bw" attribute and add this 
attribute as a media level attribute for every media line. 

If the IMS-ALG received any visited-realm instances in the SDP offer, the IMS-ALG shall supply the instance number 
one above the highest instance number in the received SDP offer as instance number within the "omr-s-att" and "omr-s- 
bw" attribute(s). Otherwise the IMS-ALG shall supply the instance number 2. 

NOTE 1 : The instance number 1 is reserved for the incoming SDP offer when it contains no visited-realm instance. 

NOTE 2: The remaining SDP session level attributes (e.g., the "o" line) are not modified by the OMR procedures. 
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5.3 Determination of codec related SDP information associated 
to a previous realm instance 

When deciding to bypass some previous MR, an IMS-ALG needs to determine the SDP information which is appHcable 
together with the visited-realm instance or secondary-realm instance that the IMS selects for the bypass (see subclause 
6.1). The IMS-ALG will include that SDP information in a forwarded SDP offer or perform additional modifications on 
top of it, e.g., to offer transcoding at its own MR. 

To determine the codec related SDP information associated to that previous realm instance for the media line, the IMS- 
ALG shall use the procedures below. 

1) If any "omr-codecs", "omr-m-att", or "omr-m-bw" attributes with a higher instance number than the previous 
visited-realm instance or secondary -realm instance exist for a media line, the IMS-ALG shall consider the 
information within the set of attributes with the lowest instance number among those as follows: 

- the IMS-ALG shall replace the transport format and media formats in the media line with the transport 
format and media formats from the "omr-codecs" attribute with this instance number; 

- the IMS-ALG shall retain all the "visited-realm", "secondary-realm", "omr-s-cksum", "omr-m-cksum", "omr- 
codecs", "omr-m-att", "omr-s-att", "omr-m-bw" and "omr-s-bw" attributes for the media line and replace all 
other SDP a-line(s) for the media line with the attributes extracted from the "omr-m-att" attribute(s) with this 
instance number; and 

NOTE 1 : This procedure only describes update to codec related SDP information. Clauses 6 and 7 describe the 
corresponding modifications to the OMR related attributes. 

the IMS-ALG shall replace the SDP b-line(s) for the media line with the b-line(s) extracted from the "omr-m- 
bw" attributes with this instance number. 

Otherwise, the IMS-ALG shall use the SDP a-lines, b-lines, transport format and list of media formats of the 
corresponding media line. 

2) If any "omr-s-att" or "omr-s-bw" attributes with a higher instance number than the previous visited-realm 
instance or secondary-realm instance exist, the IMS-ALG shall consider the information within the set of 
attributes with the lowest instance number among those as follows: 

- If the same attributes are provided for each media line, the IMS ALG shall replace all session-level SDP a- 
lines and b-lines with the encapsulated attributes and bandwidth within the "omr-s-att" attributes and "omr-s- 
bw" attributes of one media line as session level attributes and bandwidth, and may apply attribute or 
bandwidth modifier specific logic to verify and possibly adjust the session-level information from "omr-s-att" 
and "omr-s-bw" attributes and media level information determined as described above; 

NOTE 2: Verification helps in the possible event of splitting media lines by intermediate entities. 

- otherwise the IMS-ALG shall apply attribute or bandwidth modifier specific logic to derive appropriate 
session-level information from "omr-s-att" and "omr-s-bw" attributes and media level information 
determined as described above, or delete all those encapsulated attributes and all session-level SDP a-lines 
and b-lines. 

NOTE 3: In the possible event of merging of media lines by intermediate entities, there may be inconsistencies in 
the encapsulated session level a-lines and/or b-lines. 

3) Otherwise, the IMS-ALG shall use the session-level SDP a-lines and b-lines. 

For an SDP offer with several media lines, an IMS-ALG applies the OMR algorithm separately for each media line and 
can select different optimised paths. In such a case, the session-level attributes and bandwidth information determined 
by the above algorithm can differ for different optimised paths, depending on the selected visited-realm instance or 
secondary -realm instance for each media line. The IMS-ALG may then apply attribute or bandwidth modifier specific 
logic to determine the appropriate session-level information or discard conflicting information. An IMS-ALG may also 
apply a policy not to choose different optimised paths for different media to avoid such conflicts. 



ETSI 



3GPP TS 29.079 version 10.0.0 Release 10 11 ETSI TS 129 079 VI 0.0.0 (2011-04) 

NOTE 4: Upon receiving an SDP offer and validating the OMR attributes in the SDP offer, but before making any 
codec changes to the SDP offer, the IMS-ALG supporting OMR can delete any unsupported attributes 
from the SDP offer, e.g., attributes associated with capability negotiation. The IMS-ALG supporting 
OMR can also delete any ignored attributes, e.g., due to lack of support of a required extension to 
capability negotiation, as determined by the creq attribute defined in IETF RFC 5939 [20]. 

5.4 Modifying codec related information 

5.4.1 Modifying the format list 

When forwarding an SDP offer, the IMS-ALG should not make changes to the attributes associated with a format 
remaining in the format list of the m-line that require the allocation of an MR to translate the media payload between 
the format described by the received SDP offer and the format described by the forwarded SDP offer. 

NOTE 1 : Examples include changing between AMR octet-aligned and bandwidth-efficient modes, and 
incompatible AMR mode-sets. 

To add a codec to the format list of the m-line in the SDP offer to be forwarded, the IMS-ALG shall either: 

add a media format to the format list on the media line that is different from any format in the "omr-codecs" 
attributes for the media line, along with any necessary media attributes, or 

- re-insert a format from an "omr-codecs" attribute for the media line that is not in the current format list, along 
with the corresponding attributes for the format with the same instance number in "omr-m-att" attributes. 

NOTE 2: This procedure avoids the potential need to retain a media resource to perform format mapping when 
performing proactive transcoding, if the bypass decision is based on the SDP answer. 

5.4.2 Modifying preferred configurations 

When forwarding an SDP offer, the IMS-ALG supporting SDP capability negotiation shall only make a change to a 
preferred configuration in the incoming SDP offer without changing the configuration number if the change is 
backward compatible. A backward compatible change is one that, if it is selected as the actual configuration, does not 
require the allocation of an MR to translate the media payload between the format described by the received SDP offer 
and the format described by the forwarded SDP offer, and does not require modification of the actual configuration 
number when forwarding the SDP answer. This applies to the preferred configuration (pcfg) itself and any capabilities 
referenced in the pcfg. 

NOTE 1 : It is recommended that an IMS-ALG not make any codec list changes to an SDP offer that includes any 
mandatory session capabilities unless it also deletes all attributes associated with capability negotiation as 
if capability negotiation were not supported. 

To make any of the following changes to a preferred configuration in the SDP offer: 

- to change the priority of the preferred configuration with respect to others; 

- to allow insertion of a new preferred configurations with higher priority; 

to allow reassignment of another preferred configuration to a higher priority; or 

- to make any other changes to a preferred configuration that are not backward compatible and cannot be realized 
by inserting a new preferred configuration, 

the IMS-ALG shall reassign the configuration number to one unused in the SDP offer or in any of the encapsulated 
information for the media line in the SDP offer and add any necessary capability attributes. 

NOTE 2: Changing the priority of a codec or preferred configuration increases the possibility of introducing a 

transcoding function that is not otherwise needed. Normally new or changed preferred configurations are 
assigned with higher configuration numbers (of lower priority) than existing preferred configurations. 

When forwarding an SDP offer, the IMS-ALG supporting SDP capability negotiation shall not change any existing SDP 
capneg capability attributes, but may insert additional capability attributes. 
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The IMS-ALG may delete a preferred configuration from the SDP offer. However, the IMS-ALG shall not delete any 
unreferenced capability attributes. 

If the IMS-ALG desires to add a preferred configuration, it should search for an equivalent or backward compatible 
preferred configuration within the encapsulated codec related information. If it finds such a suitable preferred 
configuration, the IMS-ALG should reuse the configuration number from the encapsulated preferred configuration if the 
resulting priority with respect to other preferred configurations is acceptable. 

To add a new preferred configuration to the media line of the SDP offer that is different from and not backward 
compatible with any pcfg attribute in encapsulated codec information for the media line, the IMS-ALG shall allocate a 
new configuration number for the new preferred configuration with a configuration number unused by any other 
preferred configuration within the SDP offer or within the encapsulated codec related information. 

5.5 Additional inandling for SDP answer witii actual 
configuration 

In subclause 6.2.2 and subclause 6.2.8 step 4), if the media line in the SDP answer includes an actual configuration, the 
IMS-ALG should perform the following procedure to determine if the codecs in the SDP answer are supported by a 
previous version of the received SDP offer: 

The IMS-ALG should compare the actual configuration with SDP capneg preferred configurations in encapsulated 
codec related information to determine if previous realm instances are associated with matching codec related 
information. The actual configuration matches a preferred configuration: 

- if the preferred configuration has the same configuration number as the actual configuration; or 

- if the capabilities listed in the actual configuration match the capabilities available in the preferred 
configuration in the SDP offer. 

NOTE: An IMS-ALG can choose not to compare the SDP capneg actual configuration with encapsulated 

preferred configurations, or only to compare configuration numbers, but this may lead to a failure to find 
opportunities to bypass previous realm instances. However, SDP capneg procedures recommend that the 
offerer performs a second offer-answer exchange where the actual configuration is offered in normal 
SDP. Missed opportunities to bypass previous realm instances could still be found during this second 
offer-answer exchange. 

If the IMS-ALG selected a preferred configuration with a different configuration number than the actual configuration 
for bypassing a previous realm, the IMS-ALG shall change the capability number of the actual configuration to equal 
the capability number of the matching preferred configuration before forwarding the SDP answer. 

5.6 Procedures specific to OMR attributes 

5.6.1 General 

This subclause describes additional procedures specific to SDP attributes associated with OMR specified in 3 GPP TS 
24.229 [5]. 

5.6.2 instance-number 

When creating a new visited-realm instance for a media line in an SDP offer, the IMS-ALG shall assign an instance- 
number value for the instance that is " 1 " higher than the highest existing instance-number value for any visited-realm 
attribute for any media line in the received SDP offer, starting with the value " 1 " if there are no such attributes in the 
SDP offer. If IMS-ALG adds visited-realm instances for several media lines, it shall use the same instance-number. 

A UA creating a visited-realm instance for a media line in an SDP offer shall assign an instance-number value " 1 " for 
the instance. 
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5.6.3 Session and media checksum calculation 

An IMS ALG or UA supporting OMR shall determine a session level checksum and a media level checksum for each 
media line containing a visited-realm SDP attribute. 

The session level checksum shall be calculated by summing all the hex values of the individual ASCII characters 
(excluding all white space) of the "b" and "a" session level lines. The media level checksum shall be calculated by 
summing all the hex values of the individual ASCII characters (excluding all white space) of the "m", "b", and "a" 
media level lines , but excluding the session and media level checksum attribute lines themselves. 

When there is no "b" or "a" session level lines to calculate the session level checksum, the session level checksum is set 
to "0". 



6 IMS-ALG procedures 

6.1 IMS-ALG handling of SDP offer 



6.1.1 General 

Upon receiving an SDP offer, the IMS-ALG supporting OMR shall apply the procedures in the following subclauses for 
each media line with non-zero port value. 

6.1 .2 Validating the incoming SDP offer 

If any of the following conditions are true: 

1) the SDP offer includes any OMR attributes for the media line, but no visited-realm instance; 

2) the connection-address and port information in the visited-realm instance with the highest value of instance- 
number for the media line does not match the connection address and port information for the media line; or 

3) one of the following conditions are true: 

- the "omr-m-cksum" attribute does not match the checksum value computed for the media line as described in 
subclause 5.6.3; or 

- based on local policy, if the "omr-m-cksum" attribute matches the computed media line checksum, but the 
"omr-s-cksum" attribute does not match the checksum value computed for the session level lines as described 
in subclause 5.6.3, 

then the IMS-ALG shall remove all OMR attributes associated with the media line from the SDP offer and use the 
modified SDP offer in the procedures in the following subclauses. 

6.1 .3 Deciding whether to allocate a primary local MR and if any previous 
MR can be bypassed 

The IMS-ALG considers received information in the SDP offer and applies local policy to decide whether to allocate a 
primary local MR and if it is to bypass any previous MRs. 

NOTE: An IMS-ALG can revise these decisions when receiving the SDP answer, applying procedures in 
subclause 6.2. 

The IMS ALG shall perform the following steps: 

1) If all of the following conditions apply: 

a) local policy does not require the allocation of an MR for any non-OMR related reason (e.g. for hosted NAPT 
traversal on the incoming signalling path, or for legal interception; and 
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b) the IP realm, nettype and addrtype for the outgoing signalling path is the same as the IP realm, nettype and 
addrtype associated with a visited-realm or secondary-realm instance for the media line 

- such that the instance has an instance-number value / that is less than the highest instance-number value n 
associated with the media line in the incoming SDP offer; and 

- such that the instance / is associated with a codec list, determined using the procedures in clause 5.3, 
which includes all codecs required by local policy, unless the IMS-ALG has a policy to offer the missing 
codecs proactively without reserving an MR, 

then the IMS-ALG shall store an indication that the allocation of a primary local MR is not required and shall 
store the realm instances with instance-number greater than /, which are associated with MRs that can be 
bypassed without allocating a primary local MR. 

2) If the following condition applies: 

a) the IMS-ALG controls an MR with access to an IP realm, nettype and addrtype associated with a visited- 
realm or secondary-realm instance for the media line 

- such that the instance has an instance-number value j that is less than the highest instance-number value n 
associated with the media line in the incoming SDP offer; and 

- such that the instance j is associated with a codec list, determined using the procedures in clause 5.3, 
which includes all codecs required by local policy, unless such codecs are provided at a local MR via 
transcoding, 

then the IMS-ALG shall store the realm instances with instance-number greater than j, which are associated 
with MRs that can be bypassed when allocating a primary local MR. 

3) If all of the following conditions apply: 

a) the condition in step 1) does not apply; 

b) the IP realm, nettype and addrtype for the outgoing signalling path is the same as the IP realm, nettype and 
addrtype for the incoming signalling path; 

c) the codec list received in the SDP offer, determined from the SDP m-line and associated non-OMR attribute 
lines, includes all codecs required by local policy, unless the IMS-ALG has a policy to offer the missing 
codecs proactively without reserving an MR; and 

d) local policy does not require the allocation of an MR for any non-OMR related reason (e.g. for hosted NAPT 
traversal on the incoming signalling path, or for legal interception), 

then the IMS-ALG shall store an indication that the allocation of a primary local MR is not required and that no 
MRs can be bypassed when no primary local MR is allocated. 

4) If an indication that the allocation of a primary local MR is not required has been stored in steps 1) or 3), 

- then the IMS-ALG shall compare the realm instances (and MRs) that can be bypassed with or without 
allocation of a primary local MR, as determined in steps 1), 2) and 3), and shall use local policy to select 
whether to allocate a primary local MR, 

- else the IMS-ALG shall select to allocate a primary local MR, 

NOTE: Usually the decision is made based on which choice retains the smallest total number of MRs in the 
media path, but local policy may apply other criteria. 

5) If the IMS-ALG selected in step 4) to allocate a primary local MR, then the IMS-ALG shall: 

- if one or more realm instances can be bypassed when allocating a primary local MR, then store instance- 
number value k=j and apply the procedures in subclause 6.1.4 to bypass previous MRs, else apply the 
procedures in subclause 6.1.5 to not bypass previous MRs; and 

- apply the procedures in subclause 6.1.6 to allocate a primary local MR. 

6) If the IMS-ALG selected in step 4) to not allocate a primary local MR, then the IMS-ALG shall: 
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- if one or more realm instances can be bypassed when not allocating a primary local MR, then store instance- 
number value k=i and apply the procedures in subclause 6.1.4 to bypass previous MRs, else apply the 
procedures in subclause 6.1.5 to not bypass previous MRs; and 

- apply the procedures in subclause 6. 1 .7 to not allocate a primary local MR. 

6.1 .4 Bypassing previous MRs 

If the IMS-ALG decides (applying the criteria in subclauses 6.1.3, 6.2.2, 6.2.3 or 6.2.8) to bypass a previous MR, the 
IMS-ALG shall: 

1) use the connection address and port information from the selected instance k for the media line in the received 
SDP offer as incoming connection address and incoming port information for the media line in the subsequent 
steps; 

2) reconstruct the associated codec information for the media line in the received SDP offer from the selected 
instance k as described in subclause 5.3, and use that codec information as incoming codec information in the 
subsequent steps; and 

3) delete every OMR attribute for the media line with instance-number value higher than k. 

6.1 .5 Bypassing no previous IVIRs 

If the IMS-ALG decides (applying the criteria in subclauses 6.1.3, 6.2.2 or 6.2.3) not to bypass any previous MR, the 
IMS-ALG shall: 

1) use the connection-address from the SDP c-line in the received SDP offer as incoming connection-address in 
subsequent steps; 

2) use the port information from the SDP m-line in the received SDP offer as incoming port information in 
subsequent steps; and 

3) use the codec information from the SDP m-line and associated non-OMR attribute lines in the received SDP 
offer as incoming codec information in the subsequent steps. 

6.1 .6 Allocating a primary local MR 

If the IMS-ALG decides (applying the criteria in subclauses 6.1.3 or 6.2.3) to allocate a local MR, the IMS-ALG shall: 

1) if no MR context has been allocated due to a previous SDP offer-answer exchange, allocate an MR context with 
access to the IP realms, nettypes and addrtypes associated with the incoming connection address and port 
information determined in subclause 6.1.4 or 6.1.5, and the outgoing signalling path, respectively applying 
procedures as described in subclause 6.3; 

2) if the IMS-ALG is not performing hosted NAPT traversal on the incoming side, then insert the incoming 
connection address and incoming port information for the media line, as determined in subclause 6.1.4 or 6.1.5, 
into the remote connection address and port information for the incoming termination on the MR; 

3) if the IMS-ALG is performing hosted NAPT traversal on the incoming side, then discover the remote connection 
address and port information for the incoming termination on the MR using latching or other unspecified 
technique; 

4) if codec information is to be provided to the allocated MR on the incoming termination, provide to the MR the 
incoming codec information as determined in subclause 6.1.4 or 6.1.5; 

NOTE: The IMS-ALG can defer the allocation of an MR termination at the incoming side and the related 
procedures in steps 1) to 4) until it processes the SDP answer. 

5) if the IMS-ALG requires according to local policy that its MR remain in the media path for reasons unrelated to 
OMR, remove all OMR specific attributes from the modified SDP offer; 
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6) if there is no visited-realm instance associated with the connection address and port information for the media 
Hne in the modified SDP offer, and there is no local policy prohibiting removal of the allocated MR, then 
construct and add this visited-realm instance; 

7) replace the connection address and port information for the media line in the SDP offer with the connection 
address and port information from the MR termination on the outgoing side; 

8) make any codec changes to incoming codec information, as determined in subclause 6.1.4 or 6.1.5, according to 
local policy, taking into account the procedures in clause 5.4, and insert the changed codec information into the 
SDP m-line and associated attribute lines of the modified SDP offer; 

9) if codec information is to be provided to the allocated MR for the outgoing termination, provide to the MR the 
modified codec information derived in step 8); and 

10) add to the modified SDP offer a visited-realm instance for the IP realm associated with the connection address 
and port information for the media line in the modified SDP offer, including the incoming codec information 
encoded according to clause 5.2 if any codec changes were inserted in step 8). 



6.1 .7 Allocating no primary local MR 



If the IMS-ALG decides (applying the criteria in subclauses 6.1.3 or 6.2.2) not to allocate a primary local MR, the IMS- 
ALG shall: 

1) decide according to local policy if the IMS-ALG performs any codec changes to the incoming codec 

information, as determined in subclause 6.1.4 or 6.1.5, without allocating an MR (i.e., for proactive transcoding 
without resource reservation); 



NOTE: The IMS-ALG can only make codec changes if the available SIP signalling allows the IMS-ALG to 

initiate a 2"^ SDP offer/answer transaction if necessary to allocate a transcoding MR after receipt of the 
SDP answer, as described in subclause 6.2.3. 

2) if the IMS-ALG decided in step 1) to perform any codec changes, then 

a) if there is no visited-realm instance associated with the connection address and port information for the media 
line in the received SDP offer, then construct and add this visited-realm instance; 

b) make the codec changes to incoming codec information according to local policy, taking into account the 
procedures in clause 5.4, and insert the changed codec information into the SDP m-line and associated 
attribute lines of the modified SDP offer; and 

c) add to the modified SDP offer a visited-realm instance with the same IP realm, connection address and port 
information as the previous visited-realm instance (after a possible execution of step 3 in subclause 6.1.4 for 
the media line, including the incoming codec information encoded according to clause 5.2), 

3) if the IMS-ALG decided in step 1) not to perform any codec changes, then 

a) insert the incoming codec information, determined in subclause 6.1.4 or 6.1.5 into the SDP m-line and 
associated attribute lines of the modified SDP offer. 

4) use the incoming connection address, determined in subclause 6.1.4 or 6.1.5, as the connection address in the 
SDP c-line of the forwarded SDP offer; and 

5) use the incoming port information as determined in previous steps as port information in the SDP m-line of the 
modified SDP offer. 

6.1 .8 Allocating secondary local MRs 

According to local policy, the IMS-ALG may allocate a secondary MR for each combination of IP realm, nettype and 
addrtype on the outgoing side for which the IMS-ALG can allocate an MR context. However, if the IMS-ALG does not 
require a local MR for non-OMR reasons, the IMS ALG should only allocate a secondary MR for a combination of IP 
realm, nettype and addrtype if the IP realm, nettype and addrtype are not represented by a visited-realm or secondary- 
realm instance for the media line in the SDP offer. To allocate a secondary MR, the IMS-ALG shall: 



ETSI 



3GPP TS 29.079 version 10.0.0 Release 10 17 ETSI TS 129 079 VI 0.0.0 (2011-04) 

1) if no MR context has been allocated due to a previous SDP offer-answer exchange, allocate an MR context for 
the IP realm, nettype and addrtype on the outgoing side, using the incoming connection address and incoming 
port information for the media line, determined in subclause 6.1.4 or 6.1.5, as the remote connection address and 
port information for the incoming termination; 

2) if codec information is to be provided to the allocated MR for the incoming termination, provide to the MR the 
incoming codec information, as determined in subclause 6.1.4 or 6.1.5; 

NOTE: The IMS-ALG can defer the allocation of an MR termination at the incoming side and the related 
procedures in steps 1) and 2) until it processes the SDP answer. 

3) if any codec information is to be provided to the allocated MR for the outgoing termination, provide to the MR 
the codec information from the SDP m-line and associated attribute lines of the modified SDP offer; 

4) if the IMS-ALG did not yet add a visited-realm instance for the outgoing side (the IMS-ALG did not allocate a 
primary MR and did not perform any codec changes, see subclause 6.1.7); then 

a) if there is no visited-realm instance associated with the connection address and port information for the media 
line in the received SDP offer, then construct and add this visited-realm instance; and 

b) add to the SDP offer a visited-realm instance with the same IP realm, connection address and port 
information as the previous visited-realm instance (after a possible execution of step 3 in subclause 6.1.4 for 
the media line), 

5) add to the SDP offer a secondary-realm instance for the context allocated in step 1). 

6.1 .9 Forwarding SDP offer 

The IMS-ALG shall: 

1) if local policy forbids sending of OMR related attributes to the outgoing IP realm, the IMS-ALG shall delete all 
OMR related attributes from the SDP offer; and 

2) if the IMS-ALG has made any modifications to the received SDP offer before forwarding and the SDP offer 
includes OMR related attributes, the IMS-ALG shall compute checksum values as described in subclause 5.6.3 
and replace or add the "omr-s-cksum" and "omr-m-cksum" attributes for the media line. 

The IMS-ALG forwards the SDP offer according to 3GPP TS 24.229 [4]. 

6.2 IMS-ALG handling of SDP answer 

6.2.1 General 

Upon receiving the SDP answer corresponding to the SDP offer sent in subclause 6.1, the IMS-ALG supporting OMR 
shall perform the procedures in the following subclauses for each media line in the SDP answer. 

6.2.2 IMS-ALG bypasses an allocated transcoding MR 

The IMS-ALG uses the following conditions to determine that a previously allocated primary local MR or upstream 
MR is to be bypassed and that a second SDP offer/answer transaction is needed to update the connection information on 
the outgoing side. Two examples of this procedure are given in Annex Q of TS 23.228 [3]: steps 5) and 6) of Figure 
Q.5, and steps 7) and 8) of Figure Q.7. 

If the following conditions are true: 

1) there is no visited-realm or secondary -realm instance in the received SDP answer; and 

2) it is possible to immediately initiate another SDP offer/answer transaction towards the SDP answerer with the 
available SIP signalling, 

then the IMS-ALG should re-evaluate the conditions in subclause 6.1.3, steps 1) to 4), taking into account the 
information from the originally received SDP offer, as well as the codecs received in the SDP answer as additional 
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information (using the procedure in subclause 5.5 if the SDP answer includes an actual configuration), to select again 
whether to allocate a primary local MR and to recompute how many realm instances can be bypassed. The IMS-ALG 
should select to modify the previous decision if a higher number of realm instances can be bypassed. 

If the IMS-ALG selected in the previous step to modify the previous decision and 

- to not allocate a primary local MR that has previously been allocated; or 

- to not allocate a primary local MR and to bypass other previous realm instances than decided when previously 
evaluating subclause 6.1.3, 

then the IMS-ALG shall: 

1) apply the procedures in subclause 6.1.4 to bypass previous MRs or the procedures in subclause 6.1.5 to not 
bypass previous MRs (using information from the originally received SDP offer), depending on its 
corresponding decision; 

2) apply the procedures in subclause 6.1.7 to not allocate a primary local MR without making any codec changes; 

3) after subclauses 6.2.2 and 6.2.3 are completed as applicable for all media lines, apply the procedures in 
subclause 6.1.9 for each media line to send a second SDP offer within available SIP signalling, initiating a new 
SDP offer/answer transaction towards the SDP answerer; and 

4) upon receipt of the second SDP answer, continue handling of the second SDP answer as if it were the first, and 
reference the most recent data associated with the forwarding of the second (modified) SDP offer (i.e., incoming 
SDP information, allocated MRs and modified SDP offer) as if it occurred the first time. 

6.2.3 IMS-ALG allocates a local transcoding MR when performing 
proactive transcoding without resource reservation 

The IMS-ALG uses the procedures in this subclause if it receives an SDP answer without a realm instance, performed 
proactive transcoding without resource reservation when forwarding the SDP offer, as in step 2) of subclause 6.1.7, and 
then determines that it needs to allocate an MR for proactive transcoding. 

If all the following conditions are true: 

1) the received SDP answer includes no visited-realm or secondary -realm instance for the media line; 

2) the IMS-ALG performed proactive transcoding without resource reservation when previously forwarding the 
SDP offer, as in step 2) of subclause 6.1.7; 

3) the selected codec in the received SDP answer is not supported by the incoming media path and incoming codec 
information, as previously determined in subclause 6.1.4 or 6.1.5 (using information from the originally received 
SDP offer), indicating that an MR must be allocated to provide transcoding; and 

4) it is possible to immediately initiate another SDP offer/answer transaction towards the SDP answerer with the 
available SIP signalling, 

NOTE: If a second SDP offer/answer transaction cannot be initiated with available SIP signalling, the algorithm 
will fail to allocate a functioning end-to-end media path. 

then the IMS-ALG shall: 

1) if when previously handling the SDP offer it was determined in step 2) of subclause 6.1.3 that one or more realm 
instances can be bypassed when allocating a primary local MR (using information from the originally received 
SDP offer), then store instance-number value k=j and apply the procedures in subclause 6.1.4 to bypass previous 
MRs, else apply the procedures in subclause 6.1.5 to not bypass previous MRs (using information from the 
originally received SDP offer); 

2) apply the procedures in subclause 6.1.6 to allocate a primary local MR; 

3) apply the procedures in subclause 6.1.8 to update allocation of any secondary MRs, if necessary; 
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4) after subclauses 6.2.2 and 6.2.3 are completed as applicable for all media lines, apply the procedures in 
subclause 6.1.9 for each media line, to send a second SDP offer within available SIP signalling, and to initiate a 
new SDP offer/answer transaction towards the SDP answerer; and 

5) upon receipt of the second SDP answer, continue handling of the second SDP answer as if it were the first, and 
reference the most recent data associated with the forwarding of the second (modified) SDP offer (i.e., incoming 
information, allocated MRs and modified SDP offer) as if it occurred the first time. 

6.2.4 IMS-ALG determines steps required to complete the handling of the 
SDP answer 

The IMS-ALG performs the following steps to determine the disposition of any allocated MRs and to complete the 
handling of the SDP answer: 

1) if the received SDP answer includes a visited-realm instance for the media line, then the IMS-ALG shall apply 
the procedures in subclause 6.2.5; 

2) if the received SDP answer includes a secondary-realm instance for the media line, then the IMS-ALG shall 
apply the procedures in subclause 6.2.6; 

3) if all the following conditions are true: 

a) there is no visited-realm or secondary-realm instance in the received SDP answer; and 

b) the IMS-ALG did not allocate a primary local MR (i.e., executed subclause 6.1.7) when forwarding the SDP 
offer, 

then the IMS-ALG shall apply the procedures in subclause 6.2.7, and 

4) if neither step 1) nor step 2) nor step 3) applies, then the IMS-ALG shall apply the procedures in subclause 6.2.8 
to retain a primary local MR. 

6.2.5 Receiving a visited-realm instance 

If the IMS-ALG receives a visited-realm instance, then the IMS-ALG shall: 

1) If the visited-realm instance for the media line in the SDP answer has IP realm, instance-number, nettype and 
addrtype information that matches the visited-realm instance associated with the incoming SDP offer 
information, 

NOTE: The visited-realm instance associated with the incoming SDP offer information is either the one in the 

received SDP offer with highest instance-number (before any bypass decision is made), if one is present, 
or the one added in subclause 6.1.6 step 6) or in subclause 6.1.7 step 2a). 

then the IMS-ALG shall: 

- replace the connection address and port information for the media line in the SDP answer with the connection 
address and port information from the visited-realm instance in the received SDP answer, and 

delete the visited-realm instance from the SDP answer, 

2) else the IMS-ALG shall: 

if necessary, update the unspecified connection address information in the SDP answer with the unspecified 
address of the appropriate type for the network into which the SDP answer will be sent (i.e., IPv4: "0.0.0.0", 
IPv6: "invalid.invalid"). 

6.2.6 Receiving a secondary-realm instance 

If the IMS-ALG receives a secondary-realm instance, then the IMS-ALG shall: 

1) if the secondary -realm instance for the media line in the SDP answer has IP realm, instance-number, nettype and 
addrtype information that matches a secondary-realm instance added by the IMS-ALG when applying 
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procedures in subclause 6.1.8 then the IMS-ALG shall apply the procedures in subclause 6.2.8 to retain a 
secondary local MR, 

2) else the IMS-ALG shall: 

- if necessary, update the unspecified connection address information in the SDP answer with the unspecified 
address of the appropriate type for the network into which the SDP answer will be sent (i.e., IPv4: "0.0.0.0", 
IPv6: "invalid.invalid"). 

6.2.7 Receiving no realm instance when no primary local MR allocated 

If the IMS-ALG receives (as determined in subclause 6.2.4) an SDP answer with no realm instance after forwarding an 
SDP offer without allocating a primary local MR, then the IMS-ALG shall: 

1) If the IMS-ALG applied subclause 6.1.4 to bypass previous MRs when handling the forwarding of the SDP 
offer, then the IMS-ALG shall: 

a) copy into the media line of the SDP answer the visited-realm or secondary -realm instance from the media 
line of the received SDP offer that was used to populate the connection address and port information in the 
forwarded SDP offer, replacing the connection-address and port information in the instance with the 
connection address and port information from the received SDP answer; and 

b) replace the connection address information in the SDP answer with the unspecified address of the appropriate 
type for the network into which the SDP answer will be sent (i.e., IPv4: "0.0.0.0", IPv6: "invalid.invalid"), 

2) else the IMS-ALG did not bypass previous MRs when forwarding the SDP offer and the IMS-ALG shall not 
modify the SDP answer. 

6.2.8 Retaining a primary or secondary local MR 

If the IMS-ALG decides (applying the criteria in subclause 6.2.4 and subclause 6.2.6) to retain a primary or secondary 
local MR, the IMS-ALG shall: 

1) if the IMS-ALG received an SDP answer with no secondary-realm instance for the media line, then the IMS- 
ALG shall: 

NOTE: The IMS-ALG retains a primary local MR in this case. The IMS-ALG will never receive a visited-realm 
instance in an SDP answer when retaining a primary local MR, since the next downstream IMS-ALG will 
remove a visited-realm instance pointing to a primary local MR, if necessary, in subclause 6.2.5 step 1). 

a) update the remote connection address and port information for the outgoing termination on the selected 

primary local MR context with the connection address and port information for the media line in the received 
SDP answer, 

2) if the IMS-ALG received an SDP answer with a secondary-realm instance for the media line, 
then the IMS-ALG shall: 

a) update the remote connection address and port information for the outgoing termination on the selected 
secondary local MR context with the connection-address and port information from the secondary -realm 
instance in the received SDP answer; and 

b) delete the secondary-realm instance from the SDP answer, 

3) if the selected codecs in the SDP answer are not in the set of codecs associated with the incoming SDP offer 
information, as determined in subclause 6.1.4 or 6.1.5 when handling the SDP offer, then modify the SDP 
answer to include the codecs selected for the incoming termination of the selected local MR; 

4) if the selected MR has access to an IP realm, nettype and addrtype associated with a visited-realm or secondary- 
realm instance for the media line 

- such that the instance has an instance-number value k that is less than the highest instance-number value n 
associated with the media line in the incoming SDP offer information, previously determined in subclause 
6.1.4 or 6.1.5; and 
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- such that the instance k is associated with a codec Hst, determined using the procedures in clause 5.3, which 
includes the codecs selected for the incoming termination of the selected local MR in step 3) (using the 
procedure in subclause 5.5 if the SDP answer includes an actual configuration), 

then the IMS-ALG shall: 

a) store the realm instances with instance-number greater than k, which are associated with additional MRs that 
can be bypassed after selecting a codec for the incoming media path when allocating a primary local MR; 

b) apply the procedures in subclause 6.1.4 to bypass additional previous MRs (using information from the 
originally received SDP offer); 

c) insert the incoming connection address and incoming port information for the media line, as determined in 
step b), as the remote connection address and port information for the selected IP realm on the incoming 
termination of the selected MR; 

d) if necessary, modify the selected codec information in the SDP answer to be a valid response to the incoming 
SDP offer codec information determined in step b); 

e) if codec information is to be provided to the allocated MR on the incoming termination, provide to the MR 
the incoming codec information as determined in step d), 

5) If the IMS-ALG applied subclause 6.1.4 to bypass previous MRs when forwarding the SDP offer or in step 4b), 
then the IMS-ALG shall: 

a) copy into the media line of the SDP answer the visited-realm or secondary -realm instance from the media 
line of the received SDP offer that was used for the remote connection address and port information for the 
incoming termination on the MR, replacing the connection-address and port information in the instance with 
the local connection address and port information for the incoming termination on the selected MR; and 

b) replace the connection address information in the SDP answer with the unspecified address of the appropriate 
type for the network into which the SDP answer will be sent (i.e., IPv4: "0.0.0.0", IPv6: "invalid.in valid"), 

6) If the IMS-ALG applied subclause 6.1.5 to not bypass previous MRs when forwarding the SDP offer, and did 
not bypass previous MRs in step 4b), then the IMS-ALG shall: 

a) replace the connection address and port information for the media line in the SDP answer with the local 
connection address and port information for the incoming termination on the selected MR. 

6.2.9 Forwarding the SDP answer 

The IMS-ALG forwards the SDP answer according to 3GPP TS 24.229 [4]. 

The IMS-ALG shall release each MR for the media line, when it is no longer potentially needed for this and any other 
forked dialog. 

6.3 IMS-ALG OMR media resource operations 
6.3.1 General 

The IMS-ALG OMR procedures as specified by subclauses 6.1 and 6.2 refer to generic MR allocation operation. When 
no MR was previously allocated, e.g. during the initial SDP offer/answer exchange, this allocation will result in the 
allocation of one or more local media termination point pairs (ingress and egress) - one for the primary IP realm and 
possible additional terminations points for secondary IP realms. 

Subsequent SDP offer/answer exchanges may result in the decision that a local MR is needed. If a local MR was not 
previously allocated, then one will now be allocated. If a local MR was previously allocated that matches the resource 
information needed, then the previously allocated resource will be used. If the previously allocated local MR does not 
match the resource information needed, then the local MR will be modified to meet the current need. 

If it is determined that local MR may be by-passed or no longer needed, then any previously allocated local MRs will be 
deallocated. 
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6.3.2 IMS-ALG operations 



The OMR MR procedures in this document are appHcable to the following IMS entities that perform as IMS-ALG 
using the media resource interface operations as indicated. 

- An IBCF acting as an IMS-ALG controlHng a TrGW using the Ix interface as defined by 3GPP TS 29.162 [16] 
and 3GPPTS 29.238 [9]: 

- Reserve TrGW Connection Point; 

- Configure TrGW Connection Point, 

Reserve and Configure TrGW Connection Point; and 
Release TrGW Connection Point. 

- A P-CSCF acting as IMS-ALG controlling an IMS-AGW using the Iq interface as defined by 3GPP TS 23.334 
[15] and 3GPP TS 29.334 [10]: 

Reserve AGW Connection Point; 

- Configure AGW Connection Point; 

- Reserve and Configure AGW Connection Point; and 
Release AGW Connection Point. 

- An AS acting as B2BUA and adapting IMS-ALG procedures to control an MRF shall use one or more of the 
following: 

- IETF RFC 4240 [11] conference service; 

- IETF RFC 4117 [19]; and 

- IETF draft-ietf-mediactrl-sip-control-framework [12] and IETF draft-ietf-mediactrl-mixer-control-package 
[13]. 



7 UA Procedures 

7.1 UA sending an SDP offer 

Upon preparing an SDP offer for sending to begin an SDP offer/answer transaction, a UA supporting OMR shall 
additionally: 

1) add to the SDP offer a visited-realm instance for the IP realm associated with the connection address and port 
information for the media line in the SDP offer; 

2) for each combination of IP realm, nettype and addrtype on the outgoing side for which the UA can allocate an 
MR termination according to local policy, if the IP realm, nettype and addrtype are not associated with the media 
line in the SDP offer, allocate an MR termination for the IP realm, nettype and addrtype on the outgoing side, 
using the same codecs associated with the media line; 

3) add to the SDP offer a secondary-realm instance for each termination allocated in step 2); and 

4) compute a checksum values as described in subclause 5.6.3 and add the "omr-s-cksum" and "omr-m-cksum" 
attributes for the media line. 

The UA then sends the SDP offer according to 3GPP TS 24.229 [4]. 
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7.2 UA receiving an SDP offer 

7.2.1 General 

Upon receiving an SDP offer and selecting a codec for the media line, a UA supporting OMR shall perform the 
procedures specified in subclauses 7.2.2 and 7.2.3, and then send the SDP answer according to 3GPP TS 24.229 [4]. 

7.2.2 Validating the incoming SDP offer 

If any of the following conditions are true: 

1) the SDP offer includes any OMR attributes for the media line, but no visited-realm instance; 

2) the connection-address and port information in the visited-realm instance with the highest value of instance- 
number for the media line does not match the connection address and port information for the media line; or 

3) one of the following checksum comparison failures are true: 

- the "omr-m-cksum" attribute does not match the checksum value computed for the media line as described in 
subclause 5.6.3; or 

- based on local policy, if the "omr-m-cksum" attribute matches the computed media line checksum, but the 
"omr-s-cksum" attribute does not match the checksum value computed for the session level lines as described 
in subclause 5.6.3, 

then the UA shall remove all OMR related attributes associated with the media line. 

7.2.3 UA may choose an alternate realm instance to bypass an upstream 
MR 

If all the following conditions are true: 

1) the UA can make available a media termination in an IP realm, nettype and addrtype such that this IP realm, 
nettype and addrtype match the IP realm, nettype and addrtype of a visited-realm or secondary-realm instance for 
the media line in the SDP offer 

2) the instance does not match the connection address and port information in the SDP offer; and 

3) the instance supports the codec selected by the UA, 
then the UA shall: 

1) select the visited-realm or secondary-realm instance with the lowest value of instance-number such that the UA 
can make available a media termination in the IP realm, nettype and addrtype of the instance and the instance 
supports the codec selected by the UA; 

2) allocate a media termination in the selected IP realm, nettype and addrtype; 

3) copy into the media line of the SDP answer the selected visited-realm or secondary -realm instance from the 
media line of the received SDP offer, replacing the connection-address and port information in the instance with 
the local connection address and port information for the allocated termination; and 

4) replace the connection address information in the SDP answer with the unspecified address of the appropriate 
type for the network into which the SDP answer will be sent (i.e., IPv4: "0.0.0.0", IPv6: "invalid.in valid"). 
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7.3 UA receiving an SDP answer 

7.3.1 General 

Upon receiving the SDP answer corresponding to the SDP offer sent in subclause 7.1, the UA supporting OMR shall 
perform the procedures specified in either subclause 7.3.2 if the SDP answer included a realm instance or subclause 
7.3.3 if the SDP answer did not include a realm instance. 

7.3.2 Receiving SDP answer with OMR information 

If the received SDP answer includes a visited-realm or secondary-realm instance for the media line with IP realm, 
instance-number, nettype and addrtype that match a visited-realm or secondary-realm instance for the media line from 
the SDP offer, then the UA shall: 

1) update the remote connection address and port information for the selected outgoing termination with the 
connection-address and port information from the visited-realm or secondary-realm instance in the received SDP 
answer; and 

2) release any other MR apart from the selected MR allocated for the media line, when it is no longer potentially 
needed for any other forked dialog. 

7.3.3 Receiving SDP answer without OMR information 

If the received SDP answer includes no visited-realm or secondary-realm instance for the media line, then the UA shall: 

1) update the remote connection address and port information for the primary outgoing termination with the 
connection address and port information from the received SDP answer; and 

2) release any secondary MR allocated for the media line, when it is no longer potentially needed for any other 
forked dialog. 

7.4 UA OMR media resource operations 

7.4.1 General 

The UA OMR procedures as specified by subclauses 7.1, 7.2, and 7.3 refer to generic MR allocation operation. This 
allocation will result in the allocation of a local media termination associated with the selected IP realm. 

Subsequent SDP offer/answer exchanges may result in either the exact same local MR being allocated or possibly a 
different local MR. If the UA is able to determine that the same resource information is being requested, the existing 
allocated local MR will be used. If the previously allocated local MR does not match the resource information needed, 
then the local MR will be modified to meet the current need. 

7.4.2 UA operations 

The OMR MR procedures in this document are applicable to the following IMS entities that perform as UA using the 
media resource interface operations as indicated. 

- An AS acting as B2BUA and adapting UA procedures to control an MRF shall use one or more of the following: 

- IETF RFC 4240 [11] conference service and tone/announcement service; 

- IETF RFC 5552 [18]; and 

- IETF draft-ietf-mediactrl-sip-control-framework [12] and IETF draft-ietf-mediactrl-mixer-control-package 
[13]. 

- An MGCF acting as an UA controlHng an IM-MGW using the Mn interface as defined by 3GPP TS 29.163 [17] 
and 3GPPTS 29.332 [14]: 
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Reserve IMS Connection Point; 

Configure IMS Connection Point; 

Reserve and Configure IMS Connection Point; and 

Release IMS Connection Point. 



8 Subsequent SDP offer/answer transactions 



8.1 



General 



Any UA or IMS-ALG controlling a media stream can initiate another SDP offer/answer transaction at any time after 
first establishing the media flow, to modify characteristics of the media flow. For example, a media endpoint (IP 
address) can change, the preferred codec can change, or a server can select to insert a media function such as a tone 
generator or conference focus. Since OMR applies independently to each SDP offer/answer transaction, it is possible 
for the OMR algorithm to create a different media configuration with each subsequent SDP offer/answer transaction, 
particularly if the transaction is initiated by a different entity in the network. It is desirable to minimize the changes in 
the outcome of the OMR algorithm during subsequent SDP offer/answer transactions to those necessary to support any 
changes in the requested characteristics of the media flow. 

8.2 Procedures to minimize changes in OMR outcome 

If an IMS-ALG receives an SDP offer, and a previous OMR procedures resulted in the establishment of an media path 
from an MR controlled by that IMS-ALG in forward direction through a different IP realm than the next IP realm in the 
signalling path for the SDP offer, the IMS-ALG should add a secondary realm instance corresponding to that MR and 
the IP realm of the media path to the forwarded SDP offer. 

If an IMS-ALG receives an SDP offer, and a previous OMR procedures resulted in the establishment of an media path 
from an MR controlled by that IMS-ALG in backward direction through a different IP realm than the previous IP realm 
in the signalling path for the SDP offer, the IMS-ALG should consider and preferentially select from the options 
available in subclause 6.1.3 the earliest incoming realm instance with the same IP realm, nettype and addrtype as used 
for the existing media path in backward direction, unless a clearly superior option is available according to local policy. 

If a transcoding option at a local MR was selected in a previous SDP offer/answer transaction, the corresponding IMS- 
ALG should again offer the transcoding options currently applied at this MR during subsequent SDP offer/answer 
transactions, using proactive transcoding with resource reservation. 

If a transcoding option at a local MR was not selected in a previous SDP offer/answer transaction, the corresponding 
IMS-ALG may according to local policy continue to offer transcoding options during subsequent SDP offer/answer 
transactions. If the IMS-ALG offers transcoding options during a subsequent SDP offer/answer transaction and none of 
them were previously selected, it should perform transcoding without resource reservation. 
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Annex A (informative): 
Signalling flows 

A.1 Scope of signalling flows 

This annex gives examples of signalling flows for Optimized Media Routeing (OMR) based on the Session Initiation 
Protocol (SIP) and the Session Description Protocol (SDP). The OMR specific SDP syntax is described in 3 GPP TS 
24.229 [4]. 



A.2 Introduction 

The signalling flows in this annex are based on IP realm and IP structure in Figure A.2-1. 




UE-B 



192.0.2.4 



-►: Controll signalling path 



< ■► : Media path after OMR 

Figure A.2-1 : IP realm and IP structure. 

Operator X and operator Y have an agreement to allow roaming users and to use OMR as much as possible. 

UE-A and UE-B are mobile users roaming into the visited network X. IP addresses etc. are obtained as described in 
3GPPTS 24.229 [4]. 

The operator X implements the IBCF policy to allow OMR optimization of anchoring if originating UE is a visiting/ 
roaming user respectively if terminating UE is a visiting/roaming user. 

The operator Y implements the IBCF policy to allow OMR optimization of anchoring if home UE is visiting/roaming in 
another network. 
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A.3 Media bypassing all IMS-ALGs 
A.3.1 General 

This subclause provides an example of a call where the media is bypassing all IMS-ALG and sent directly between the 
UEs. 

A.3. 2 Message flow 

This subclause describes the scenario when two mobile user A and B roams into a visited network X and both users 
belongs to the same operator Y. 

Preconditions: 

- Both user A and B are registered to the Home IMS network Y via the visited operator X network; 

the visited operator X and the operator of user A and B IMS home network Y have an agreement to allow media 
to be bypassed using OMR; 

- both user A and B are connected to IP realm Xa of the visited operator network X; 

- the AMR codec is allowed and accepted by all involved entities; and 

no B2BUA manipulating SDP is connected in the intermediate IM CN subsystem. 
Figure A. 3. 2-0 shows the message flow for the scenario. 
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Visited networl< X 



1 r 



Home IIVIS networl< Y (of user A and B) 



Visited networl< X 



1 r 



—Realm: Xa.operatorX.net— 



Realm: 

^X. operatorX.net, ►^ 

Y.operatorY.net ! 



—Realm Yb.operatorY.net— 



Realm: 
>-' -^. operatorX.net, ► 
I Y.operatorY.net 



—Realm: Xa.operatorX.net— 



UE-A 

192.0.2. 



_1. INVITE^ 

[c=192.0.2.1] 



^ 16. 183 _ 

[c= 192.0.2.4] 



-17. PRACK-* 

32. 200 0K_ 
"" (PRACK) 
33. UPDATE^ 

[c=192.0.2.1] 



_2. INVITE 

[c=192.0.2.1]~^ 



^ 15. 183 _ 

[c=192.0.2.4] 



31.200OK_ 
"" (PRACK) 

34. UPDATE 

[c=192.0.2.1] ^ 



IBCF-2 

3.24.1.2 190.1.1E 



3. INVITE 

[0=34.24.1.1, 

_visited-realm:1_. 

192.0.2.1, 

visited-realm:2 

34.24.1.1] 



14. 183 

[0=0.0.0.0, 

visited-realm:1 

192.0.2.4] 



35. UPDATE 

[0=34.24.1.1, 
. visited-realm:1 ^ 



192.0.2.1, 

visited-realm:2 

34.24.1.1] 



46. 200 OK 
(UPDATE) 



Intermediate IIVl CN 
subsystem entities X 



4. INVITE 

[0=190.1.15.2, 
visited-realm:1 192.0.2.1, 



13. 183 

I [0=0.0.0.0, 

visited-realm:1 192.0.2.4] 



36. UPDATE 

[0=34.24.1.1, 

— visited-realm:1 192.0.2.1,1 

visited-realm:2 

34.24.1.1] 



45. 200 OK 
, (UPDATE) _ 

[0=0.0.0.0, 
visited-realm:1 192.0.2.4] 



5. INVITE 

[0=190.1.15.2, 
visited-realm:1 192.0.2.1, 
visited-realm:2 H 

34.24.1.1, 

visited-realm: 3 

190.1.15.2] 



12. 183 

I- [0=0.0.0.0, 

visited-realm:1 192.0.2.4] 



37. UPDATE 

[0=190.1.15.2, 
visited-realm: 1 192.0.2.1, 
visited-realm:2 H 

34.24.1.1, 

visited-realm: 3 

190.1.15.2] 



44. 200 OK 
^ (UPDATE) _ 

[0=0.0.0.0, 
visited-realm: 1 192.0.2.4] 




IBCF-4 

192.0.2.3 



6. INVITE 

[0=13.24.1.1, 

_visited-realm:1_, 

192.0.2.1, 

visited-realm:2 

13.24.1.1] 



11. 183 

[0=0.0.0.0, 

visited-realm: 1 

192.0.2.4] 



38. UPDATE 

[0=13.24.1.1, 
visited-realm: 1 , 

192.0.2.1, 
visited-realm:2 

13.24.1.1] 



43. 200 OK 
(UPDATE) 

•" [0=0.0.0.0, - 

visited-realm:1 

192.0.2.4] 



7. INVITE 

_ [0=192.0.2.1, _, 

visited-realm:1 

192.0.2.1] 



10. 183 

[0=192.0.2.4, _ 

visited-realm:1 

192.0.2.4] 



26. 200 0K_ 
*" (PRACK) 



39. UPDATE 

[0=192.0.2.1, , 
visited-realm: 1 
192.0.2.1] 

42. 200 OK 
(UPDATE) 

*" [0=192.0.2.4, - 

visited-realm: 1 

192.0.2.4] 



_8. INVITE 

[0=192.0.2.1] 



9. 183 

[0=192.0.2.4] 



25. 200 0K_ 
*" (PRACK) 



.40. UPDATE^ 

[0=192.0.2.1] 

41. 200 OK 
♦ (UPDATE) - 



Figure A.3.2-1 : Signalling flow for media bypassing all IMS ALGs. 

NOTE: For clarity, the SIP 100 (Trying) messages are not shown in the signalHng flow. 
The steps of the flow are as follows: 

1. INVITE request (UE-A to P-CSCF-A) - see example in table A.3.2-1. 

The UE-A sends a SIP INVITE request including an SDP offer according to 3GPP TS 24.229 [4]. 
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Table A.3.2-1 : SIP INVITE request (UE-A to P-CSCF-A) 



INVITE SIP: user_B@operator_Y.net; SIP/2.0 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = 

t = 

C=IN IP4 192.0.2.1 

m=audio 49170 RTP/AVP 96 97 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxpt ime : 2 



2. INVITE request (P-CSCF-A to IBCF-1) - see example in table A.3.2-1. 

The P-CSCF-A uses the procedures in subclauses 6.1.5, 6.1.7 and 6.1.9 since no MR could be bypassed and no 
MR is allocated. 

The P-CSCF-A: 

- uses the connection-address from the SDP c-line as incoming connection-address in subsequent steps; 

- uses the port information from the SDP m-line as incoming port information in subsequent steps; 
uses the codec information from the SDP m-line in subsequent steps; 

- inserts the incoming codec information into the SDP m-line and associated attribute lines of the modified 
SDP offer; 

- uses the incoming connection address as the connection address in the SDP c-line of the forwarded SDP 
offer, and 

use the incoming port information as port information in the SDP m-line of the modified SDP offer. 

The P-CSCF-A then selects an IBCF, IBCF-1, in the IP realm "Xa.operatorX.net" and forwards the INVITE 
request with the SDP offer to the IBCF-1 according to 3GPP TS 24.229 [4]. 

3. INVITE request (IBCF-1 to IBCF-2) - see example in table A.3.2-3 

The IBCF-1 uses the procedures in subclauses 6.1.5, 6.1.6 and 6.1.9 since no previous realm instance offers an 
opportunity to bypass a previous MR and a local MR is required for IP realm matching. 

The IBCF-1: 

- uses the connection-address from the SDP c-line as incoming connection-address in subsequent steps; 

- uses the port information from the SDP m-line as incoming port information in subsequent steps; 
uses the codec information from the SDP m-line in subsequent steps; 

- allocates an MR context with access to the IP realms and addrtypes associated with the incoming and 
outgoing signalling paths; 

- inserts the incoming connection address and incoming port information for the media line into the remote 
connection address and port information for the incoming termination on the MR; 

- provides to the MR the incoming codec information; 
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- replaces the connection address and port information for the media Hne in the SDP offer with the connection 
address and port information from the MR termination on the outgoing side; 

constructs and adds a visited-realm instance for the media Hne in the received SDP offer to the modified SDP 
offer; 

- adds to the modified SDP offer a visited-realm instance for the IP realm associated with the connection 
address and port information for the media line in the modified SDP offer, including the incoming codec; and 

- computes a checksum value for the media line as described in subclause 5.6.3 and adds the "omr-m-cksum" 
attributes for the media line. 

The IBCF-1 then selects an IBCF, IBCF-2, in the IP realm "X. operatorX.net, Y. operatorY.net" and forwards the 
INVITE request with the SDP offer to the IBCF-2 according to 3GPP TS 24.229 [4]. 

Table A.3.2-3: SIP INVITE request (IBCF-1 to IBCF-2) 



INVITE SIP: user_B@operator_Y.net; SIP/2.0 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = 

t = 

C=IN IP4 13.24.1.1 

m=audio 62111 RTP/AVP 96 97 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 2 

visited-realm: 1 Xa . operatorX . net IN IP4 192.0.2.1 49170 

visited-realm: 2 X. operatorX.net , Y. operatorY.net IN IP4 13.24.1.1 62111 

omr-m-cksum= ( . . ) 



4-5. INVITE request (IBCF-2 to IBCF-3 via intermediate IMS CN subsystem entities) - see example in 
table A.3.2-4. 

The IBCF-2 uses the procedure in subclauses 6.1.5, 6.1.6 and 6.1.9 since no realm instance offers an opportunity 
to bypass a previous MR and a local MR is required for IP realm matching. 

The IBCF-2: 

- uses the connection-address from the SDP c-line as incoming connection-address in subsequent steps; 
uses the port information from the SDP m-line as incoming port information in subsequent steps; 

- uses the codec information from the SDP m-line and associated non-OMR attribute lines as incoming codec 
information in subsequent steps; 

- allocates an MR context with access to the IP realms, nettypes and addrtypes associated with the incoming 
and outgoing signalling paths, respectively, applying procedures as described in subclause 6.3, 

insert the incoming connection address and incoming port information for the media line into the remote 
connection address and port information for the incoming termination on the MR; 

- provides to the MR the incoming codec information; 

- replaces the connection address and port information for the media line in the SDP offer with the connection 
address and port information from the MR termination on the outgoing side; 
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- adds to the modified SDP offer a visited-realm instance for the IP realm associated with the connection 
address and port information for the media Hne in the modified SDP offer, including the incoming codec; and 

- computes a checksum value for the media line as described in subclause 5.3.4 and adds the "omr-m-cksum" 
attributes for the media line. 

The IBCF-2 forwards the INVITE request to the intermediate IMS CN subsystem entities in IP realm 
"Yb.operatorY.net" according to 3GPP TS 24.229 [4]. 

None of the intermediate IMS CN subsystem entities manipulated with the SDP offer but the identity of 
user B ©operator Y.net in the Request-URI is change to the contact address, i.e. UE-B@operatorX.net. 

The intermediate IMS CN subsystem entities select an IBCF, IBCF-3, and forward the INVITE request with the 
SDP offer to the IBCF-3 according to 3GPP TS 24.229 [4]. 

Table A.3.2-4: SIP INVITE request (IBCF-2 to IBCF-3 via intermediate IMS CN subsystem entities) 



INVITE SIP: sip: UE-B@operatorX.net; SIP/2 . 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = 

t = 

C=IN IP4 190.1.15.2 

m=audio 11324 RTP/AVP 96 07 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 2 

visited-realm: 1 Xa . operatorX . net IN IP4 192.0.2.1 49170 

visited-realm: 2 X. operatorX.net , Y. operatorY.net IN IP4 13.24.1.1 62111 

visited-realm: 3 Yb.operatorY.net IN IP4 190.1.15.2 11324 

omr-m-cksum= ( . . ) 



6. INVITE request (IBCF-3 to IBCF-4) - see example in table A.3.2-6. 

The IBCF-3 uses the procedures in subclauses 6.1.4, 6.1.7 and 6.1.9 since a previous realm instance exists that 
can be used to bypass a previous MR, IBCF-2, and bypass is allowed according to operator X and operator Y 
agreements, and the previous realm instance match the outgoing IP realm so that no local MR is required. 

The IBCF-3: 

uses the connection address and port information for the media line in the SDP offer with the connection- 
address and port information from the selected instance 2 as incoming connection address and incoming port 
information for the media line; 

- deletes the visited-realm instance 3; 

inserts the incoming codec information into the SDP m-line and associated attribute lines of the modified 
SDP offer; 

uses the incoming connection address as the connection address in the SDP c-line of the forwarded SDP 
offer; 

- uses the incoming port information as port information in the SDP m-line of the modified SDP offer; and 

- computes a checksum value for the media line as described in subclause 5.3.4 and adds the "omr-m-cksum" 
attributes for the media line. 
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The IBCF-3 then selects an IBCF, IBCF-4, in the IP realm "X.operatorX.net, Y. operatorY.net" and forwards the 
SDP offer according to 3GPP TS 24.229 [4] to IBCF-4. 

Table A.3.2-6: SIP INVITE request (IBCF-3 to IBCF-4) 



INVITE SIP: sip: UE-B@operatorX.net; SIP/2 . 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = 

t = 

C=IN IP4 13.14.1.1 

m=audio 62111 RTP/AVP 96 07 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 2 

visited-realm:l Xa.operatorX.net IN IP4 192.0.2.1 49170 

visited-realm:2 X.operatorX.net, Y. operatorY.net IN IP4 13.24.1.1 62111 

omr-m-cksum= ( . . ) 



7. INVITE request (IBCF-4 to P-CSCF B) - see example in table A.3.2-7. 

The IBCF-4 uses the procedures in subclauses 6.1.4, 6.1.7 and 6.1.9 since a previous realm instance exists that 
can be used to bypass a previous MR, IBCF-1, and the previous realm instance match the outgoing IP realm so 
that no local MR is required. 

The IBCF-4: 

uses the connection address and port information for the media line in the SDP offer with the connection- 
address and port information from the selected instance 1 as incoming connection address and incoming port 
information for the media line; 

- deletes the visited-realm instance 2; 

inserts the incoming codec information into the SDP m-line and associated attribute lines of the modified 
SDP offer; 

- uses the incoming connection address as the connection address in the SDP c-line of the forwarded SDP 
offer; 

- uses the incoming port information as port information in the SDP m-line of the modified SDP offer; and 

- computes a checksum value for the media line as described in subclause 5.3.4 and adds the "omr-m-cksum" 
attributes for the media line. 

The IBCF-4 forwards the INVITE request with the SDP offer to the P-CSCF-B, in the IP realm 
"X.operatorX.net" according to 3GPP TS 24.229 [4]. 
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Table A.3.2-7: SIP INVITE request (IBCF-4 to P-CSCF B) 



INVITE SIP: sip: UE-B@operatorX.net; SIP/2 . 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = 

t = 

C=IN IP4 192.0.2.1 

m=audio 49170 RTP/AVP 96 97 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 2 

visited-realm:l Xa.operatorX.net IN IP4 192.0.2.1 49170 

omr-m-cksum= ( . . ) 



8. INVITE request (P-CSCF to UE- B) - see example in table A.3.2-8. 

The P-CSCF-B uses the procedures in subclauses 6.1.5, 6.1.7 and 6.1.9 since no previous realm instance offers 
an opportunity to bypass an MR and no local MR is required to match the incoming realm to the outgoing realm. 

- uses the connection-address from the SDP c-line as incoming connection-address; 

- uses the port information from the SDP m-line as incoming port information; 

uses the codec information from the SDP m-line and associated non-OMR attribute lines as incoming codec 
information; and 

- according to the local policy, deletes the visited-realm "visited-realm: 1 Xa.operatorX.net IN IP4 192.0.2.1 
49170" and the "omr-m-cksum=(. . .)" from the SDP offer. 

The P-CSCF-B forwards the INVITE request with the SDP offer to the UE-B according to 3GPP TS 24.229 [4]. 
Table A.3.2-8: SIP INVITE request (P-CSCF to UE-B) 



INVITE SIP: sip: UE-B@operatorX.net; SIP/2 . 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = 

t = 

C=IN IP4 192.0.2.1 

m=audio 4 917 RTP/AVP 96 97 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxpt ime : 2 



9. 183 (Session Progress) response (UE-B to P-CSCF-B) - see example in table A.3.2-9. 

The UE accepts the codec and sends a 183 (Session Progress) response with an SDP answer indicating that 
resources are not yet available to P-CSCF-B according to 3GPP TS 24.229 [4]. 
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Table A.3.2-9: 183 (Session Progress) response (UE-B to P-CSCF-B) 



SIP/2.0 183 Session Progress 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = - 

C = IN IP4 192 .0.2.4 

t = 

m=audio 16511 RTP/AVP 97 98 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 AMR 

a=fmtp:98 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:97 telephone -event 

a=maxptime : 2 



10. 183 (Session Progress) response (P-CSCF-B to IBCF-4) - see example in table A.3.2-9 

The P-CSCF-B uses the procedures in subclauses 6.2.6 and 6.2.8 since no primary local MR was allocated. 
The P-CSCF-B: 

- does not modify the SDP answer and forwards the 183 (Session Progress) response with the SDP answer to 
IBCF-4 according to 3GPP TS 24.229 [4]. 

11. 183 (Session Progress) response (IBCF-4 to IBCF-3) - see example in table A.3.2-11 

The IBCF-4 uses the procedures in subclause 6.2.6 since no primary local MR was allocated. 
The IBCF-4: 

- copies into the media line of the SDP answer the visited-realm instance 1 from the media line of the received 
SDP offer that was used to populate the connection address and port information in the forwarded SDP offer, 
replacing the connection-address and port information in the instance with the connection address and port 
information from the received SDP answer; and 

- replaces the connection address information in the SDP answer with the unspecified IPv4 address. 

The IBCF-4 forwards the 183 (Session Progress) response with SDP answer to IBCF-3 according to 3GPP TS 
24.229 [4]. 

Table A.3.2-11 183 (Session Progress) response (IBCF-4 to IBCF-3) 



SIP/2.0 183 Session Progress 
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SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = - 

C=IN IP4 0.0.0.0 

t = 

m=audio 16511 RTP/AVP 97 98 

a=curr:qos local none 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 AMR 

a=fmtp:98 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:97 telephone -event 

a=maxptime : 2 

visited-realm: 1 Xa.operatorX.net IN IP4 192.0.2.4 



12-13. 183 (Session Progress) response (IBCF-3 to IBCF-2 via intermediate IMS CN subsystem entities) - see 
example in table A.3.2-11 

The IBCF-3 uses the procedures in subclauses 6.2.5 and 6.2.8 since the SDP answer contained a realm instance 
matching one in the received SDP offer and since no primary local MR was allocated. 

The IBCF-3: 

copies into the media line of the SDP answer the visited-realm instance 1 from the media line of the received 
SDP offer that was used to populate the connection address and port information in the forwarded SDP offer, 
replacing the connection-address and port information in the instance with the connection address and port 
information from the received SDP answer. 

The IBCF-3 then forwards the 183 (Session Progress) response with SDP answer to intermediate IMS CN 
subsystem entities according to 3GPP TS 24.229 [4]. 

The intermediate IMS CN subsystem entities do not modify the SDP answer and forwards the 183 (Session 
Progress) response with SDP answer to IBCF-2 according to 3GPP TS 24.229 [4]. 

14. 183 (Session Progress) response (IBCF-2 to IBCF-1) - see example in table A.3.2-11 

The IBCF-2 uses the procedures in subclauses 6.2.5 and 6.2.8 since the SDP answer contained a realm instance 
matching one in the received SDP offer and the local MR allocated in step 4 can be bypassed. 

The IBCF does not modify the SDP answer since the visited-realm instance does not match the information in 
the SDP offer. 

The IBCF-2 forwards the 183 (Session Progress) response with SDP answer to IBCF-1 according to 3GPP TS 
24.229 [4]. 

The IBCF-2 retains the primary local MR allocated in step 4, until it is no longer potentially needed for this and 
any other forked dialog. 

15. 183 (Session Progress) response (IBCF-1 to P-CSCF-A) - see example in table A.3.2-15 

The IBCF-1 uses the procedures in subclauses 6.2.5 and 6.2.8 since the SDP answer contained a realm instance 
matching one in the received SDP offer and the local MR allocated in step 4 can be bypassed. 

The IMS-ALG: 

- replaces the connection address and port information for the media line in the SDP answer with the 

connection address and port information from the visited-realm instance in the received SDP answer; and 

deletes the visited-realm instance 1 from the SDP answer. 

The IBCF-1 forwards the 183 (Session Progress) response with SDP answer to P-CSCF-A according to 3GPP 
TS 24.229 [4]. 
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The IBCF-1 retains the primary local MR allocated in step 3, until it is no longer potentially needed for this and 
any other forked dialog. 

Table A.3.2-15: 183 (Session Progress) response (IBCF-1 - P-CSCF-A) 



SIP/2.0 183 Session Progress 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = - 

C = IN IP4 192 .0.2.4 

t = 

m=audio 16511 RTP/AVP 97 98 

a=curr:qos local none 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 AMR 

a=fmtp:98 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:97 telephone -event 

a=maxptime : 2 



16. 183 (Session Progress) response (P-CSCF-A to UE-A) - see example in table A.3.2-15 

The P-CSCF-A forwards the 183 (Session Progress) with the SDP answer to the UE-A according to 3GPP TS 
24.229 [4]. 

17-24. PRACK request (UE-A to UE-B via P-CSCF-A, IBCF-1, IBCF-2, intermediate IMS CN subsystem 
entities, IBCF-3, IBCF-4 and P-CSCF-B). 

The UE-A acknowledge the reception of the SDP offer and the 183 (Session Progress) response by means of a 
PRACK request. 

25-32. 200 (OK) response to the PRACK request (UE-B to UE-A via P-CSCF-B, IBCF-4, IBCF-3, 
intermediate IMS CN subsystem entities, IBCF-2, IBCF-1 and P-CSCF-A). 

The UE-B acknowledges the reception of the PRACK request by means of a 200 (OK) response. 

33. UPDATE request (UE-A to P-CSCF-A) - see example in table A.3.2-33. 

When the UE-B has got resources reserved the UE-B sends an UPDATE request. 

The SDP offer in the UPDATE the request is the same as the SDP offer in the INVITE request in the step 1 with 
the only exception that "a=curr:qos local none" is now changed to "a=curr:qos local sendrecv". 
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Table A.3.2-33: UPDATE request (UE-A to P-CSCF-A) 



UPDATE SIP: sip :UE-A@operatorX . net ; SIP/2 . 

SIP headers according to 3GPP TS 24.229 [4] 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933616 IN IP4 192.0.2.4 

s = - 

C = IN IP4 192 .0.2.4 

t = 

m=audio 16511 RTP/AVP 97 98 

a=curr:qos local none 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 AMR 

a=fmtp:98 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:97 telephone -event 

a=maxpt ime : 2 



34-40. UPDATE request (P-CSCF-A to UE-B via IBCF-1, IBCF-2, intermediate IMS CN subsystem entities, 
IBCF-3, IBCF-4 and P-CSCF-B). 

34) When the P-CSCF-A receives the UPDATE request the P-CSCF-A performs the same actions as P-CSCF-A 
in step 2. 

35) When the IBCF-1 receives the UPDATE request the IBCF-1 performs the same actions as in step 3. 

36) When the IBCF-2 receives the UPDATE request the IBCF-2 performs the same actions as in step 4. 

37) Intermediate IMS CN subsystem entities do not manipulate the SDP offer. 

38) When the IBCF-3 receives the UPDATE request the IBCF-3 performs the same actions as in step 6. 

39) When the IBCF-4 receives the UPDATE request the IBCF-4 performs the same actions as in step 7. 

40) When the P-CSCF-B receives the UPDATE request the P-CSCF-B performs the same actions as in step 8. 

41. 200 (OK) response to the UPDATE request (UE-B to P-CSCF-B) - see example in table A.3.2-41. 

The UE-B acknowledges the reception of the UPDATE request by means of a 200 (OK) response containing 
SDP answer. 
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Table A.3.2-41 : 200 (OK) response to the UPDATE request (UE-B to P-CSCF-B). 



SIP/2.0 200 OK 

Via: 

To: <sip:user_A@operator_Y.net>; tag=17182 8 

From: <sip : user_B@operator_Y . net> ; tag=543210 

Call -ID: Cb03a0s09a2sdfglkj4 9023 7 

CSeq: 

P- Preferred- Identity : 

Contact : sip:UE-B@operatorX.net ;gr=urn:uuid: 354faf -7dad-22al-bl23-8a0d21f 676f 

Allow: 

Content-Type: application/sdp 

Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.4 

s = 

t = 

C=IN IP4 192.0.2.1 

m=audio 4 917 RTP/AVP 97 98 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxpt ime : 2 



42-48. 200 (OK) response to the UPDATE request (P-CSCF-B to UE-A via IBCF-4, IBCF-3, intermediate 
IMS CN subsystem entities, IBCF-2 and IBCF-1). 

42. When P-CSCF-B receives the 200 (OK) response to the UPDATE request the P-CSCF-B performs the same 
actions as in step 10. 

43. When IBCF-4 receives the 200 (OK) response to the UPDATE request the IBCF-4 performs the same 
actions as in step 1 1 . 

44. When IBCF-3 receives the 200 (OK) response to the UPDATE request the IBCF-3 performs the same 
actions as in step 12. 

45. The intermediate IMS CN subsystem entities do not manipulate the SDP answer. 

46. When IBCF-2 receives the 200 (OK) response to the UPDATE request the IBCF-2 performs the same 
actions as in step 14. 

47. When IBCF-1 receives the 200 (OK) response to the UPDATE request the IBCF-1 performs the same actions 
as in step 15. 

48. When P-CSCF-A receives the 200 (OK) response to the UPDATE request the P-CSCF-A performs the same 
actions as in step 16. 

49-56. 180 (Ringing) response (UE-B to UE-A via P-CSCF-B, IBCF-4, IBCF-3, intermediate IMS CN 
subsystem entities, IBCF-2, IBCF-1 and P-CSCF-A). 

The 1 80 (Ringing) response does not contain SDP hence no OMR specific action is required. 

57-64. 200 (OK) response to the INVITE request (UE-B to UE-A via P-CSCF-B, IBCF-4, IBCF-3, 
intermediated IMS CN subsystem, IBCF-2, IBCF-1 and P-CSCF-A). 

The User B accepts the call and the UE-B sends a 200 (OK) response to the INVITE request. The response 
contains no SDP hence no OMR specific action is required. 

65-72. ACK request (UE-A to UE-B via P-CSCF-A, IBCF-1, IBCF-2, intermediated IMS CN subsystem, 
IBCF-3, IBCF-4 and P-CSCF-B). 

The UE-B acknowledges the reception of the 200 (OK) response by means of a 200 (OK) response. 
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A.4 Proactive transcoder without resource reservation 
A.4.1 General 

This subclause provides an example of a call where a transcoding MR adds the AMR codec to the initial SDP offer 
without MR allocation. 

The UE selects the added codec and the IMS-ALG need to reserve MR and send an UPDATE request with the IP 
address and port number of the allocated MR. 

The IMS-ALG transcodes between the AMR-WB codec and the AMR codec when the call is established. 

Figure A. 1-1 in subclause A.l shows the realm and IP structure used in the examples. 

A.4. 2 Message flow 

The user A at UE-A and the user B at UE-B are roaming into a visited network X and both users belong to the same 
operator Y. 

Preconditions: 

- Both user A and B are registered to the Home IMS network Y via the visited operator X network; 

the visited operator X and the operator of user A and B IMS home network Y have an agreement to allow media 
to be bypassed using OMR; 

- both user A and B are connected to realm Xa of the visited operator network X; 

- the AMR-WB codec is allowed and accepted by all involved entities. However, the local policy of operator X is 
that the AMR codec shall always be included in the initial SDP offers towards a UE in the operator X network; 
and 

no B2BUA manipulating SDP is connected in the intermediate IM CN subsystem. 

Figure A.4. 2-1 shows the message flow for the scenario. 
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,_ [AMR-WB, _ 

0=0.0.0.0, 

visited-realm:1 

192.0.2.3] 



-58. 180- 



66. 200 0K_ 
(INVITE) 



-71. ACK- 



Intermediate IM CM 
subsystem entities X 



4. INVITE 

[AMR-WB, 

0=190.1.15.2, 

_visited-realm:1 192.0.2.1,_ 

visited-realm:2 

13.24.1.1, 

visited-realm: 3 

190.1.15.2] 



21. 183 

[AMR-WB, 
• 0=0.0.0.0, 

visited-realm: 1 192.0.2.3] 



-28. PRACK- 

33. 200 0K_ 
(PRACK) 



40. UPDATE 

[AMR-WB, 
0=190.1.15.2, 

visited-realm: 1 192.0.2. 1,_| 

visited-realm:2 

13.24.1.1, 

visited-realm: 3 

190.1.15.2] 

49. 200 OK 
(UPDATE) 

•- [AMR-WB, 

0=0.0.0.0, 
visited-realm: 1 192.0.2.3] 



-57. 180- 



65. 200 0K_ 
(INVITE) 



72. ACK- 

■ AMR-WB 



IBCF-3 

190.1.15.3 13.24.1.3 



5. INVITE 

[AMR-WB, 

0=190.1.15.2, 

_visited-realm:1 192.0.2.1, 

visited-realm:2 

34.24.1.1, 

visited-realm: 3 

190.1.15.2] 




20. 183 

[AMR-WB, 
■" 0=0.0.0.0, 

visited-realm: 1 192.0.2.3] 



-29. PRACK- 

32. 200 0K_ 
(PRACK) 



41. UPDATE 

[AMR-WB, 

0=190.1.15.2, 

_visited-realm:1 192.0.2.1, 

visited-realm:2 

34.24.1.1, 
visited-realm: 3 

190.1.15.2] 

48. 200 OK 

(UPDATE) 

•- [AMR-WB, 

0=0.0.0.0, 

visited-realm: 1 192.0.2.3] 



-56. 180- 



64. 200 0K_ 
(INVITE) 



-73. ACK- 



IBCF-4 



13.24.1.4 192.0.2.3 



19. 183 

[AMR-WB, 

h 0=0.0.0.0, - 

visited-realm: 1 

192.0.2.3] 



-30. PRACK-^ 

31.200OK_ 
(PRACK) 



42. UPDATE 

[AMR-WB, 

0=13.24.1.1, 

- visited-realm: 1 -• 

192.0.2.1, 

visited-realm:2 

13.24.1.1] 

47. 200 OK 
(UPDATE) 

^^ [AMR-WB, _ 

0=0.0.0.0, 

visited-realm: 1 

192.0.2.3] 



-55. 180- 



63. 200 0K_ 
(INVITE) 



-74. ACK- 



P-CSCF B 



7. INVITE 

[AMR-WB and 

AMR, . 
0=192.0.2.1, 
visited-realm: 1 
192.0.2.1] 

10. 183 

[AMR, 

h 0=192.0.2.4, - 

visited-realm: 1 

192.0.2.4] 

-11. PRACKh 



15. UPDATE 

[AMR, -» 
0=192.0.2.3] 

18. 200 OK 
(UPDATE) _ 

[AMR, 
0=192.0.2.4] 



43. UPDATE 

[AMR, -» 
0=192.0.2.3] 



46. 200 OK 
^ (UPDATE) _ 

[AMR, 
0=192.0.2.4] 



-54. 180- 



62. 200 0K_ 
■" (INVITE) 



75. ACK- 

^ AMR- 




8. INVITE 

JAMR-WB and 
AMR, "• 
0=192.0.2.1] 



9. 183 

- [AMR, — 
0=192.0.2.4] 

-12. PRACKh 



16. UPDATE 

[AMR, -t 
0=192.0.2.3] 

17. 200 OK 
(UPDATE) _ 

[AMR, 
0=192.0.2.4] 



44. UPDATE 

[AMR, *■ 

0=192.0.2.3] 



45. 200 OK 
^ (UPDATE) _ 

[AMR, 
0=192.0.2.4] 



-53. 180- 



61.200OK_ 
■" (INVITE) 



-76. ACK- 
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Visited networl< X 



Home IIVIS network Y (of user A and B) 



Visited networl< X 



-Realm: Xa.operatorX.net- 




Realm: 
.operatorX.net,^'-^— 
Y. operatorY.net 



-Realm Yb.operatorY.net— 



Realm: 
— ►■ -^X.operatorX.net> 
I Y. operatorY.net 



-Realm: Xa.operatorX.net- 



UE-A 

192.0.2.1 



P-CSCFA 



1. INVITE 

- [AMR-WB - 
c=192.0.2.1] 



20. 183 

- [AMR-WB, - 
c=1 92.0.2.3] 



-21. PRACKH 

36. 200 0K_ 
(PRACK) 



37. UPDATE 

- [AMR-WB, -I 
c=192.0.2.1] 



52. 200 OK 

I- (UPDATE) - 

[c=1 92.0.2.3] 



-^—60. 180- 



68. 200 0K_ 
(INVITE) 



-69. ACK— ► 



IBCF-1 

192.0.2.2 , 13.24.1.1 



2. INVITE 

- [AMR-WB - 
c=192.0.2.1] 



19.183 

- [AMR-WB, - 
c=1 92.0.2.3] 



-22. PRACKH 

35. 200 0K_ 
(PRACK) 



38. UPDATE 

- [AMR-WB, -I 
c=192.0.2.1] 



51. 200 OK 
,_ (UPDATE) _ 

[AMR-WB, 
c=192.0.2.3] 



-59. 180- 



67. 200 0K_ 
■" (INVITE) 



-70. ACK— ► 



IBCF-2 



13.24.1.2 190.1.15.2 



3. INVITE 

[AMR-WB, 

0=34.24.1.1, 

-visited-realm:H 

192.0.2.1, 

visited-realm:2 

34.24.1.1] 



18.183 

[AMR-WB, 

t- 0=0.0.0.0, - 

visited-realm:1 

192.0.2.3] 



-23. PRACK-^ 



34. 200 0K_ 
(PRACK) 



39. UPDATE 

[AMR-WB, 

0=34.24.1.1, 

-visited-realm:1 ^ 

192.0.2.1, 

visited-realm:2 

34.24.1.1] 

50. 200 OK 
(UPDATE) 

,_ [AMR-WB, _ 

0=0.0.0.0, 

visited-realm:1 

192.0.2.3] 



-58. 180- 



66. 200 0K_ 
(INVITE) 



-71. ACK— ► 



Intermediate IM CM 
subsystem entities X 



4. INVITE 

[AMR-WB, 

0=190.1.15.2, 

_visited-realm:1 192.0.2.1,_ 

visited-realm:2 

13.24.1.1, 

visited-realm: 3 

190.1.15.2] 



17. 183 

[AMR-WB, 
• 0=0.0.0.0, 

visited-realm: 1 192.0.2.3] 



-24. PRACK- 

33. 200 0K_ 
(PRACK) 



40. UPDATE 

[AMR-WB, 
0=190.1.15.2, 

visited-realm: 1 192.0.2. 1,_| 

visited-realm:2 

13.24.1.1, 

visited-realm: 3 

190.1.15.2] 

49. 200 OK 
(UPDATE) 

•- [AMR-WB, 

0=0.0.0.0, 
visited-realm: 1 192.0.2.3] 



-57. 180- 



65. 200 0K_ 
(INVITE) 



72. ACK H 

■AMR-WB 



IBCF-3 

190.1.15.3 13.24.1.3 



5. INVITE 

[AMR-WB, 

0=190.1.15.2, 

_visited-realm:1 192.0.2.1, 

visited-realm:2 

34.24.1.1, 

visited-realm: 3 

190.1.15.2] 



16. 183 

[AMR-WB, 
"" 0=0.0.0.0, 

visited-realm: 1 192.0.2.3] 



-25. PRACK- 

32. 200 0K_ 
(PRACK) 



41. UPDATE 

[AMR-WB, 

0=190.1.15.2, 

_visited-realm:1 192.0.2.1, 

visited-realm:2 

34.24.1.1, 
visited-realm: 3 

190.1.15.2] 

48. 200 OK 

(UPDATE) 

•- [AMR-WB, 

0=0.0.0.0, 

visited-realm: 1 192.0.2.3] 



-56. 180- 



64. 200 0K_ 
(INVITE) 



-73. ACK- 



IBCF-4 



13.24.1.4 192.0.2.3 



6. INVITE 

[AMR-WB, 

0=13.24.1.1, 

-visited-realm: 1-> 

192.0.2.1, 

visited-realm:2 

13.24.1.1] 



15. 183 

[AMR-WB, 

t 0=0.0.0.0, - 

visited-realm: 1 

192.0.2.3] 



-26. PRACKH 

31.200OK_ 
(PRACK) 



42. UPDATE 

[AMR-WB, 

0=13.24.1.1, 

- visited-realm: 1 -» 

192.0.2.1, 

visited-realm:2 

13.24.1.1] 

47. 200 OK 
(UPDATE) 

^ [AMR-WB, _ 

0=0.0.0.0, 

visited-realm: 1 

192.0.2.3] 



-55. 180- 



63. 200 0K_ 
(INVITE) 



-74. ACK— ► 



P-CSCF B 



7. INVITE 

[AMR-WB and 

AMR, _^ 
0=192.0.2.1, 
visited-realm: 1 
192.0.2.1] 

10. 183 

[AMR, 

e 0=192.0.2.4, - 

visited-realm: 1 

192.0.2.4] 

11. UPDATE 

[AMR, -» 
0=192.0.2.3] 



14. 200 OK 
(UPDATE) _ 

[AMR, 
0=192.0.2.4] 



-27. PRACKH 

30. 200 0K_ 
(PRACK) 



43. UPDATE 

[AMR, -» 
0=192.0.2.3] 



46. 200 OK 
^ (UPDATE) _ 

[AMR, 
0=192.0.2.4] 



-54. 180- 



62. 200 0K_ 
■" (INVITE) 



75. ACK— ► 

^ AMR- 



UE-B 

192.0.2.4 



8. INVITE 

JAMR-WB and 
AMR, "• 
0=192.0.2.1] 



9. 183 

I- [AMR, — 
0=192.0.2.4] 

12. UPDATE 

[AMR, H 
0=192.0.2.3] 



13. 200 OK 
_ (UPDATE) _ 

[AMR, 
0=192.0.2.4] 



-28. PRACK-^ 

29. 200 OK 

(PRACK) 



44. UPDATE 

[AMR, »■ 

0=192.0.2.3] 



45. 200 OK 
^ (UPDATE) _ 

[AMR, 
0=192.0.2.4] 



-53. 180- 



61.200OK_ 
■" (INVITE) 



-76. ACK- 



Figure A.4.2-1 : Message flow for proactive transcoder without resource reservation. 

NOTE: For clarity, the SIP 100 (Trying) messages are not shown in the signalHng flow. 

The steps of the flow are as follows: 

1. INVITE request (UE-A to P-CSCF-A) - see example in table A.4.2-1. 

The UE-A sends a SIP INVITE request according to 3GPP TS 24.229 [4]. The INVITE request includes an SDP 
offer proposing the use of the AMR-WB codec and inband DTMF. 
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Table A.4.2-1 : SIP INVITE request (UE-A to P-CSCF-A) 



INVITE SIP: user_B@operator_Y.net; SIP/2.0 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = 

C=IN IP4 192 .0.2.1 

m=audio 49170 RTP/AVP 96 97 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:96 telephone -event 

a=rtpmap:97 AMR-WB/16000/l 

a=fmtp:97 mode-change-capability=2 ; max-red=220 

a=ptime : 2 

a=maxptime : 24 



2. INVITE request (P-CSCF-A to IBCF-1) - see example in table A.4.2-1. 

The P-CSCF-A uses the procedures in subclauses 6.1.5, 6.1.7 and 6.1.9 since no MR could be bypassed and no 
MR is allocated. 

The P-CSCF-A: 

- uses the connection-address from the SDP c-line as incoming connection-address; 

- uses the port information from the SDP m-line as incoming port information; 
uses the codec information from the SDP m-line; 

- inserts the incoming codec information into the SDP m-line and associated attribute lines of the modified 
SDP offer; 

- uses the incoming connection address as the connection address in the SDP c-line of the forwarded SDP 
offer, and 

use the incoming port information as port information in the SDP m-line of the modified SDP offer. 

The P-CSCF-A then selects an IBCF, IBCF-1, in the realm "Xa.operatorX.net" and forwards the INVITE request 
with the SDP offer to the IBCF-1 according to 3GPP TS 24.229 [4]. 

3. INVITE request (IBCF-1 to IBCF-2) - see example in table A.4.2-3 

The IBCF-1 uses the procedures in subclauses 6.1.5, 6.1.6 and 6.1.9 since no previous realm instance offers an 
opportunity to bypass a previous MR and a local MR is required for realm matching. 

The IBCF-1: 

- uses the connection-address from the SDP c-line as incoming connection-address; 

- uses the port information from the SDP m-line as incoming port information; 
uses the codec information from the SDP m-line; 

- allocates an MR context with access to the IP realms and addrtypes associated with the incoming and 
outgoing signalling paths; 

- inserts the incoming connection address and incoming port information for the media line into the remote 
connection address and port information for the incoming termination on the MR; 

- provides to the MR the incoming codec information; 
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- replaces the connection address and port information for the media Hne in the SDP offer with the connection 
address and port information from the MR termination on the outgoing side; 

constructs and adds a visited-realm instance for the media Hne in the received SDP offer to the modified SDP 
offer; 

- adds to the modified SDP offer a visited-realm instance for the IP realm associated with the connection 
address and port information for the media line in the modified SDP offer, including the incoming codec; and 

- computes a checksum value for the media line as described in subclause 5.3.4 and adds omr-m-cksum 
attributes for the media line. 

The IBCF-1 then selects an IBCF, IBCF-2, in the realm "X. operatorX.net, Y. operatorY.net" and forwards the 
INVITE request with the SDP offer to the IBCF-2 according to 3GPP TS 24.229 [4]. 

Table X.2.2-3: SIP INVITE request (IBCF-1 to IBCF-2) 



INVITE SIP: user_B@operator_Y.net; SIP/2.0 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = 

C=IN IP4 13.24.1.1 

m=audio 62111 RTP/AVP 96 97 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:96 telephone -event 

a=rtpmap:97 AMR-WB/16000/l 

a=fmtp:97 mode-change-capability=2 ; max-red=220 

a=ptime : 2 

a=maxptime : 24 

visited-realm: 1 Xa . operatorX . net IN IP4 192.0.2.1 49170 

visited-realm: 2 X. operatorX.net , Y. operatorY.net IN IP4 13.24.1.1 62111 

omr-m-cksum= ( . . ) 



4-5. INVITE request (IBCF-2 to IBCF-3 via intermediate IMS CN subsystem entities) - see example in 
table A.4.2-4. 

The IBCF-2 uses the procedure in subclauses 6.1.5, 6.1.6 and 6.1.9 since no realm instance offers an opportunity 
to bypass a previous MR and a local MR is required for realm matching. 

The IBCF-2: 

- uses the connection-address from the SDP c-line as incoming connection-address; 
uses the port information from the SDP m-line as incoming port information; 

- uses the codec information from the SDP m-line and associated non-OMR attribute lines as incoming codec 
information; 

- allocates an MR context with access to the IP realms and addrtypes associated with the incoming and 
outgoing signalling paths, respectively, applying procedures as described in subclause 6.3, 

insert the incoming connection address and incoming port information for the media line into the remote 
connection address and port information for the incoming termination on the MR; 

- provides to the MR the incoming codec information; 

- replaces the connection address and port information for the media line in the SDP offer with the connection 
address and port information from the MR termination on the outgoing side; 
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- adds to the modified SDP offer a visited-realm instance for the IP realm associated with the connection 

address and port information for the media Hne in the modified SDP offer, including the incoming codec; and 

forwards the INVITE request to the intermediate IMS CN subsystem entities in realm "Yb.operatorY.net" 
according to 3GPP TS 24.229 [4]. 

None of the intermediate IMS CN subsystem entities manipulated with the SDP offer but the identity of 
user B ©operator Y.net in the Request-URI is change to the contact address, i.e. UE-B@operatorX.net. 

The intermediate IMS CN subsystem entities select an IBCF, IBCF-3, and forward the INVITE request with the 
SDP offer to the IBCF-3 according to 3GPP TS 24.229 [4]. 

Table A.4.2-4: SIP INVITE request (IBCF-2 to IBCF-3 via intermediate IMS CN subsystem entities) 



INVITE SIP: sip: user_B@operatorX.net; SIP/2.0 




SIP headers according to 3GPP TS 24.229 [4] 




Content-Type: application/sdp 




Content -Length: (...) 




v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 




s = 

C=IN IP4 190.1.15.2 




m=audio 11324 RTP/AVP 96 97 




a=curr:qos local none 




a=curr:qos remote none 




a=des:qos mandatory local sendrecv 




a=des:qos none remote sendrecv 




a=rtpmap:96 telephone -event 




a=rtpmap:97 AMR-WB/16000/l 




a=fmtp:97 mode-change-capability=2 ; max-red=220 




a=ptime:20 




a=maxptime:24 




visited-realm: 1 Xa.operatorX.net IN IP4 192.0.2.1 49170 




visited-realm: 2 X. operatorX.net , Y. operatorY.net IN IP4 13.24.1 


1 62111 


visited-realm: 3 Yb.operatorY.net IN IP4 190.1.15.2 11324 




omr-m-cksum= ( . . ) 





6. INVITE request (IBCF-3 to IBCF-4) - see example in table A.4.2-6. 

The IBCF-3 uses the procedures in subclauses 6.1.4, 6.1.7 and 6.1.9 since a previous realm instance exists that 
can be used to bypass a previous MR, IBCF-2, and bypass is allowed according to operator X and operator Y 
agreements, and the previous realm instance match the outgoing realm so that no local MR is required. 

The IBCF-3: 

uses the connection address and port information for the media line in the SDP offer with the connection- 
address and port information from the selected instance 2 as incoming connection address and incoming port 
information for the media line; 

- deletes the visited-realm instance 3; 

- inserts the incoming codec information into the SDP m-line and associated attribute lines of the modified 
SDP offer; 

- uses the incoming connection address as the connection address in the SDP c-line of the forwarded SDP 
offer; 

uses the incoming port information as port information in the SDP m-line of the modified SDP offer; and 

- selects an IBCF, IBCF-4, in the realm "X. operatorX.net, Y. operatorY.net" and forwards the SDP offer 
according to 3GPP TS 24.229 [4] to IBCF-4. 
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Table A.4.2-6: SIP INVITE request (IBCF-3 to IBCF-4) 



INVITE SIP: sip: UE-B@operatorX.net; SIP/2 . 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = 

C=IN IP4 13.14.1.1 

m=audio 62111 RTP/AVP 96 97 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:96 telephone -event 

a=rtpmap:97 AMR-WB/16000/l 

a=fmtp:97 mode-change-capability=2 ; max-red=220 

a=ptime : 20 

a=maxptime : 24 

visited-realm:l Xa.operatorX.net IN IP4 192.0.2.1 49170 

visited-realm:2 X. operatorX.net , Y. operatorY.net IN IP4 13.24.1.1 62111 

omr-m-cksum= ( . . ) 



7. INVITE request (IBCF-4 to P-CSCF B) - see example in table A.4.2-7. 

The IBCF-4 uses the procedures in subclauses 6.1.4, 6.1.7 and 6.1.9 since a previous realm instance exists that 
can be used to bypass a previous MR, IBCF-1, and the previous realm instance match the outgoing realm so that 
no local MR is required. 

The IBCF-4: 

- uses the connection address and port information from the selected instance 1 for the media line in the SDP 
offer as incoming connection address and incoming port information; 

- reconstructs the associated codec information for the media line in the SDP offer from the selected instance 1 
as described in subclause 5.3; 

deletes the OMR attribute for the media line with instance-number 2; 

- decides, according to the local policy (the operator X implements a local policy to always offer AMR if not 
included in an SDP offer from an external network) to add the AMR codec as follows: 

o inserts the changed codec information into the SDP m-line and associated attribute lines of the modified 
SDP offer; and 

o adds to the modified SDP offer a visited-realm instance with the same IP realm, connection address and 
port information as the previous visited realm instance, 

- uses the incoming connection address as the connection address in the SDP c-line of the forwarded SDP 
offer; and 

- uses the incoming port information as determined in previous steps as port information in the SDP m-line of 
the modified SDP offer; 

- computes checksum values as described in subclause 5.6.3 and replaces the "omr-m-cksum" attributes for the 
media line; and 

- forwards the INVITE request with the SDP offer to the P-CSCF-B, in the realm "X. operatorX.net" according 
to3GPPTS24.229[4]. 
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Table A.4.2-7: SIP INVITE request (IBCF-4 to P-CSCF B) 



INVITE SIP: sip: UE-B@operatorX.net; SIP/2 . 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = 

C=IN IP4 192 .0.2.1 

m=audio 49170 RTP/AVP 96 97 98 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:96 telephone -event 

a=rtpmap:97 AMR-WB/16000/l 

a=fmtp:97 mode-change-capability=2 ; max-red=220 

a=rtpmap:98 AMR/8000/l 

a=fmtp:98 mode-change-capability=2 ; max-red=220; octet-align=l 

a=ptime : 2 

a=maxptime : 24 

visited-realm:l Xa.operatorX.net IN IP4 192.0.2.1 49170 

omr-codec:l audio 49170 RTP/AVP 96 97 98 rtpmap:96 telephone -event rtpmap:97 AMR-WB/16000/l 

fmtp:97 mode-change-capability=2 ; max-red=22 

omr-m-att:l a=curr:qos local none 

omr-m-att:l curr:qos remote none 

omr-m-att:l des:qos mandatory local sendrecv 

omr-m-att:l des:qos none remote sendrecv 

omr-m-att:l ptime:20 

omr-m-att:l maxptime:240 

omr-m-ck:sum= ( . . ) 



8. INVITE request (P-CSCF to UE- B) - see example in table A.4.2-8. 

The P-CSCF-B uses the procedures in subclauses 6.1.5, 6.1.7 and 6.1.9 since no previous realm instance offers 
an opportunity to bypass an MR and no local MR is required to match the incoming realm to the outgoing realm. 

uses the connection-address from the SDP c-line as incoming connection-address; 

- uses the port information from the SDP m-line as incoming port information; 

- uses the codec information from the SDP m-line and associated non-OMR attribute lines as incoming codec 
information; 

- according to the local policy, deletes all OMR attributes from the SDP offer; and 

- forwards the INVITE request with the SDP offer to the UE-B according to 3GPP TS 24.229 [4]. 
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Table A.4.2-8: SIP INVITE request (P-CSCF to UE-B) 



INVITE SIP: sip: UE-B@operatorX.net; SIP/2 . 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.1 

s = 

C=IN IP4 192 .0.2.1 

m=audio 49170 RTP/AVP 96 97 98 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:96 telephone -event 

a=rtpmap:97 AMR-WB/16000/l 

a=fmtp:97 mode-change-capability=2 ; max-red=220 

a=rtpmap:98 AMR/8 0/1 

a=fmtp:98 mode-change-capability=2 ; max-red=220; octet-align=l 

a=ptime : 2 

a=maxptime : 24 



9. 183 (Session Progress) response (UE-B to P-CSCF-B) - see example in table A.4.2-9. 

The UE accepts the AMR codec and sends a 183 (Session Progress) response with an SDP offer indicating that 
resources are not yet available to P-CSCF-B according to 3GPP TS 24.229 [4]. 

Table A.4.2-9: 183 (Session Progress) response (UE-B to P-CSCF-B) 



SIP/2.0 183 Session Progress 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2312345678 IN IP4 192.0.2.1 

s = - 

C = IN IP4 192 .0.2.4 

m=audio 16511 RTP/AVP 96 98 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:96 telephone -event 

a=rtpmap:98 AMR/8 0/1 

a=fmtp:98 mode-change-capability=2 ; max-red=220; octet-align=l 

a=ptime : 2 

a=maxptime : 24 



10. 183 (Session Progress) response (P-CSCF-B to IBCF-4) - see example in table A.4.2-9 

The P-CSCF-B uses the procedures in subclauses 6.2.6 and 6.2.8 since no primary local MR was allocated. 

The P-CSCF-B: 

does not modify the SDP answer and forwards the 183 (Session Progress) response with the SDP answer to 
IBCF-4 according to 3GPP TS 24.229 [4]. 

11-12. PRACK request (IBCF-4 to UE-B via P-CSCF-B). 

The IBCF-4 acknowledge the receiption of the SDP offer and the 183 (Session Progress) response by means of a 
PRACK request. 

13-14. 200 (OK) response to the PRACK request (UE-B to IBCF-4). 
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The UE-B acknowledges the receiption of the PRACK request by means of a 200 (OK) response. 

15. UPDATE request (IBCF-4 to P-CSCF-B) - see example in table A.4.2-15 

The IBCF-4 determines by subclause 6.2.3 that an MR is needed since the UE-B selected the codec added by 
IBCF-4 in flow-step 7. The IBCF-4 uses subclause 6.1.5, 6.1.6 and 6.1.9 since no IMS-ALG can be bypassed 
and a primary MR is allocated. 

The IBCF-4: 

uses the connection-address from the SDP c-line in the original SDP offer as incoming connection-address in 
subsequent steps; 

- uses the port information from the SDP m-line in the original SDP offer as incoming port information in 
subsequent steps; 

use the codec information from the SDP m-line and associated non-OMR attribute lines in the original SDP 
offer as incoming codec information in the subsequent steps; 

- allocates an MR context with access to the IP realms, nettypes and addrtypes associated with the incoming 
connection address and port information and the outgoing signalling path; 

- inserts the incoming connection address and incoming port information for the media line into the remote 
connection address and port information for the incoming termination on the MR; 

- provides to the MR the incoming codec information; 

- remove all OMR specific attributes from the modified SDP offer; 

- replaces the connection address and port information for the media line in the SDP offer with the connection 
address and port information from the MR termination on the outgoing side; 

adds to the modified SDP offer a visited-realm instance for the IP realm associated with the connection 
address and port information for the media line in the modified SDP offer; 

- computes checksum values as described in subclause 5.6.3 and replace or add the "omr-s-cksum" and "omr- 
m-cksum" attributes for the media line; and 

- forwards the UPDATE request with the SDP answer to P-CSCF-B according to 3GPP TS 24.229 [4]. 

Table A.4.2-15: UPDATE request (IBCF-4 to P-CSCF-B) 



UPDATE SIP: sip : UE-B@operatorX . net ; SIP/2 . 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2087654321 IN IP4 192.0.2.1 

s = 

C=IN IP4 192.0.2.3 

m=audio 23561 RTP/AVP 96 98 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:96 telephone -event 

a=rtpmap:98 AMR/8000/l 

a=fmtp:98 mode-change-capability=2 ; max-red=220; octet-align=l 

a=ptime : 2 

a=maxptime : 24 

visited-realm: 3 Xa.operatorX.net IN IP4 192.0.2.3 23561 

omr-m-cksum= ( . . ) 



16. UPDATE request (P-CSCF-B to UE- B) - see example in table A.4.2-16. 
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The P-CSCF-B uses the procedures in subclauses 6.1.5, 6.1.7 and 6.1.9 since no previous realm instance offers 
an opportunity to bypass an MR and no local MR is required to match the incoming realm to the outgoing realm. 

- uses the connection-address from the SDP c-line as incoming connection-address; 

- uses the port information from the SDP m-line as incoming port information; 

uses the codec information from the SDP m-line and associated non-OMR attribute lines as incoming codec 
information; and 

- according to the local policy, deletes the visited-realm "visited-realm:l Xa.operatorX.net IN IP4 192.0.2.3 
23561" and the "omr-m-cksum=(..)" from the SDP offer. 

The P-CSCF-B forwards the UPDATE request with the SDP offer to the UE-B according to 3GPP TS 24.229 
[4]. 

Table A.4.2-16: SIP UPDATE request (P-CSCF-B to UE-B) 



UPDATE SIP: sip : UE-B@operatorX . net ; SIP/2 . 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2087654321 IN IP4 192.0.2.1 

s = 

C=IN IP4 192.0.2.3 

m=audio 23561 RTP/AVP 96 98 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:96 telephone -event 

a=rtpmap:98 AMR/8 0/1 

a=fmtp:98 mode-change-capability=2 ; max-red=220; octet-align=l 

a=ptime : 20 

a=maxptime : 24 



17. 200 (OK) response (UE-B to P-CSCF-B) - see example in table A.4.2-17. 

The UE accepts the AMR codec (again) and sends a 200 (OK) response to the UPDATE request with an SDP 
answer still indicating that resources are not yet available to P-CSCF-B according to 3GPP TS 24.229 [4]. 

Table A.4.2-17: 200 (OK) response to UPDATE request (UE-B to P-CSCF-B) 



SIP/2.0 200 OK 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2312345678 IN IP4 192.0.2.1 

s = - 

C=IN IP4 192.0.2.4 

m=audio 16511 RTP/AVP 96 98 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:96 telephone -event 

a=rtpmap:98 AMR/8 0/1 

a=fmtp:98 mode-change-capability=2 ; max-red=220; octet-align=l 

a=ptime : 20 

a=maxptime : 24 
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18. 200 (OK) response (P-CSCF-B to IBCF-4) - see example in table A.4.2-17. 

The P-CSCF-B uses the procedures in subclauses 6.2.6 and 6.2.8 since no primary local MR was allocated. 

The P-CSCF-B: 

does not modify the SDP answer and forwards the 200 (OK) response with the SDP answer to IBCF-4 
according to 3GPP TS 24.229 [4]. 

19. 183 (Session Progress) response (IBCF-4 to IBCF-3) - see example in table A.4.2-19. 

The IBCF-4 continues from the point when the 183 (Session Progress) response was received in flow-step 11 
and uses the procedures in subclauses 6.2.8 and 6.2.9 since the IBCF-4 retains the MR allocated in flow-step 11. 

The IBCF-4: 

- updates the remote connection address and port information for the outgoing termination on the selected MR 
context with the connection address and port information for the media line in the received SDP answer; 

- copies into the media line of the SDP answer the visited-realm instance 1 from the media line of the received 
SDP offer that was used for the remote connection address and port information for the incoming termination 
on the MR, replacing the connection-address and port information in the instance with the local connection 
address and port information for the incoming termination on the selected MR; 

- replaces the connection address information in the SDP answer with the unspecified IPv4 address; and 

- forwards 183 (Session Progress) response with the SDP answer to IBCF-3 according to 3GPP TS 24.229 [4]. 

Table A.4.2-19 183 (Session Progress) response (IBCF-4 to IBCF-3) 



SIP/2.0 183 Session Progress 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2087654321 IN IP4 192.0.2.3 

s = - 

C=IN IP4 0.0.0.0 

m=audio 2 3 563 RTP/AVP 97 98 

a=curr:qos local none 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR-WB/16 0/l 

a=fmtp:97 mode-change-capability=2 ; max-red=220 

a=rtpmap:97 telephone -event 

a=maxptime : 2 

a=maxptime : 24 

visited-realm: 1 Xa.operatorX.net IN IP4 192.0.2.3 



20-21. 183 (Session Progress) response (IBCF-3 to IBCF-2 via intermediate IMS CN subsystem entities) - see 
example in table A.4.2-19 

The IBCF-3 uses the the procedures in subclauses 6.2.5 and 6.2.9 since a visited-realm instance was received. 

The IBCF-3 forwards the 183 (Session Progress) response with an unmodified SDP answer to the intermediate 
IMS CN subsystem entities according to 3GPP TS 24.229 [4]. 

The intermediate IMS CN subsystem entities do not modify the SDP answer and forwards the 183 (Session 
Progress) response with the SDP answer to IBCF-2 according to 3GPP TS 24.229 [4]. 

22. 183 (Session Progress) response (IBCF-2 to IBCF-1) - see example in table A.4.2-19 

The IBCF-2 uses the the procedures in subclauses 6.2.5 and 6.2.9 since a visited-realm instance was received and 
the local MR allocated in step 4 can be bypassed. 
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The IBCF-2 forwards the 183 (Session Progress) response with an unmodified SDP answer to IBCF-1 according 
to3GPPTS24.229[4]. 

The IBCF-2 retains the primary local MR allocated in step 4, until it is no longer potentially needed for this and 
any other forked dialog. 

23. 183 (Session Progress) response (IBCF-1 to P-CSCF-A) - see example in table A.4.2-23 

The IBCF-1 uses the the procedures in subclauses 6.2.5 and 6.2.9 since a visited-realm instance was received and 
the local MR allocated in step 4 can be bypassed. 

The IBCF-1: 

- replaces the connection address and port information for the media line in the SDP answer with the 

connection address and port information from the visited-realm instance in the received SDP answer; and 

deletes the visited-realm instance 1 from the SDP answer. 

The IBCF-1 forwards the 183 (Session Progress) response with SDP answer to P-CSCF-A according to 3GPP 
TS 24.229 [4]. 

The IBCF-1 retains the primary local MR allocated in step 3, until it is no longer potentially needed for this and 
any other forked dialog. 

Table X.2.2-23: 183 (Session Progress) response (IBCF-1 - P-CSCF-A) 



SIP/2.0 183 Session Progress 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2087654321 IN IP4 192.0.2.3 

s = - 

C=IN IP4 192.0.2.3 

m=audio 23 563 RTP/AVP 97 98 

a=curr:qos local none 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR-WB/16 0/l 

a=fmtp:97 mode-change-capability=2 ; max-red=220 

a=rtpmap:97 telephone -event 

a=maxptime : 2 

a=maxptime : 24 



24. 183 (Session Progress) response (P-CSCF-A to UE-A) - see example in table A.4.2-23 

The P-CSCF-A forwards the 183 (Session Progress) with the SDP answer to the UE-A according to 3GPP TS 
24.229 [4]. 

25-30. PRACK request (UE-A to UE-B via P-CSCF-A, IBCF-1, IBCF-2, intermediate IMS CN subsystem 
entities, IBCF-3, IBCF-4 and P-CSCF-B). 

The UE-A acknowledge the receiption of the SDP offer and the 183 (Session Progress) response by means of a 
PRACK request. 

31-36. 200 (OK) response to the PRACK request (UE-B to UE-A via P-CSCF-B, IBCF-4, IBCF-3, 
intermediate IMS CN subsystem entities, IBCF-2, IBCF-1 and P-CSCF-A). 

The UE-B acknowledges the receiption of the PRACK request by means of a 200 (OK) response. 

37. UPDATE request (UE-A to P-CSCF-A) - see example in table A.4.2-18. 

When the UE-A has got resources reserved the UE-A sends an UPDATE request. 
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The SDP offer in the UPDATE the request is the same as the SDP offer in the INVITE request in the step 1 with 
the only exception that "a=curr:qos local none" is now changed to "a=curr:qos local sendrecv". 

Table X.2.2-18: UPDATE request (UE-A to P-CSCF-A) 



UPDATE SIP: sip :UE-A@operatorX . net ; SIP/2 . 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933616 IN IP4 192.0.2.1 

s = 

C=IN IP4 192.0.2.1 

m=audio 49170 RTP/AVP 96 97 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:96 telephone -event 

a=rtpmap:97 AMR-WB/16 0/l 

a=fmtp:97 mode-change-capability=2 ; max-red=220 

a=ptime : 2 

a=maxpt ime : 2 4 



38-42. UPDATE request (P-CSCF-A to IBCF-4 via IBCF-1, IBCF-2, intermediate IMS CN subsystem 
entities and IBCF-3). 

38) When the P-CSCF-A receives the UPDATE request the P-CSCF-A performs the same actions as P-CSCF-A 
in step 2. 

39) When the IBCF-1 receives the UPDATE request the IBCF-1 performs the same actions as in step 3. 

40) When the IBCF-2 receives the UPDATE request the IBCF-2 performs the same actions as in step 4. 

41) Intermediate IMS CN subsystem entities do not manipulate the SDP offer. 

42) When the IBCF-3 receives the UPDATE request the IBCF-3 performs the same actions as in step 6. 

43. UPDATE request (IBCF-4 to P-CSCF-B) - see example in table A.4.2-43. 

The IBCF-4 uses the procedures in subclauses 6.1.5, 6.1.6 and 6.1.9 since an MR is needed (already allocated in 
flow- step 11) and no previous MR can be bypassed. 

The IBCF-4: 

- uses the connection-address from the SDP c-line as incoming connection-address in subsequent steps; 

- uses the port information from the SDP m-line as incoming port information in subsequent steps; 

uses the codec information from the SDP m-line and associated non-OMR attribute lines as incoming codec 
information in the subsequent steps; 

- inserts the incoming connection address and incoming port information for the media line into the remote 
connection address and port information for the incoming termination on the MR; 

- removes all OMR specific attributes from the modified SDP offer; 

- replaces the connection address and port information for the media line in the SDP offer with the connection 
address and port information from the MR termination on the outgoing side; 

- adds the AMR-WB codec changes to incoming codec information and insert the changed codec information 
into the SDP m-line and associated attribute lines of the modified SDP offer; 

adds to the modified SDP offer the visited-realm instance for the IP realm associated with the connection 
address and port information for the media line in the modified SDP offer, including the incoming codec 
information encoded according to clause 5.2 if any codec changes were inserted in step 8); 
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- computes checksum values as described in subclause 5.6.3 and adds the "omr-m-cksum" attributes for the 
media line; and 

- forwards the UPDATE request with the modified SDP offer to P-CSCF-B according to 3GPP TS 24.229 [4]. 

Table A.4.2-43: SIP UPDATE request (IBCF-4 to P-CSCF-B) 



UPDATE SIP: sip : UE-B@operatorX . net ; SIP/2 . 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2087654321 IN IP4 192.0.2.1 

s = 

C=IN IP4 192 .0.2.3 

m=audio 23561 RTP/AVP 96 98 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:96 telephone -event 

a=rtpmap:98 AMR/8000/l 

a=fmtp:98 mode-change-capability=2 ; max-red=220; octet-align=l 

a=ptime : 2 

a=maxptime : 24 

visited-realm:3 Xa . operatorX . net IN IP4 192.0.2.3 23561 

omr-m-cksum= ( . . ) 



44. UPDATE request (P-CSCF-B to UE-B) - see example in table A.4.2-43. 

When the P-CSCF-B receives the UPDATE request the P-CSCF-B performs the same actions as in step 8. 

45. 200 (OK) response to the UPDATE request (UE-B to P-CSCF-B) - see example in table X.2.2-41. 

The UE-B acknowledges the receiption of the UPDATE request by means of a 200 (OK) response containing 
SDP answer. 

Table X.2.2-41 : 200 (OK) response to the UPDATE request (UE-B to P-CSCF-B). 



SIP/2.0 200 OK 

SIP headers according to 3GPP TS 24.229 [4] 

Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP4 192.0.2.4 

s = 

t = 

C=IN IP4 192.0.2.1 

m=audio 4 917 RTP/AVP 97 98 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxpt ime : 2 



46-52. 200 (OK) response to the UPDATE request (P-CSCF-B to UE-A via IBCF-4, IBCF-3, intermediate 
IMS CN subsystem entities, IBCF-2 and IBCF-1). 

46. When P-CSCF-B receives the 200 (OK) response to the UPDATE request the P-CSCF-B performs the same 
actions as in step 14. 



ETSI 



3GPP TS 29.079 version 10.0.0 Release 10 54 ETSI TS 129 079 VI 0.0.0 (2011-04) 

47. When IBCF-4 receives the 200 (OK) response to the UPDATE request the IBCF-4 performs the same 
actions as in step 15. 

48. When IBCF-3 receives the 200 (OK) response to the UPDATE request the IBCF-3 performs the same 
actions as in step 16. 

49. The intermediate IMS CN subsystem entities do not manipulate the SDP answer. 

50. When IBCF-2 receives the 200 (OK) response to the UPDATE request the IBCF-2 performs the same 
actions as in step 18. 

51. When IBCF-1 receives the 200 (OK) response to the UPDATE request the IBCF-1 performs the same actions 
as in step 19. 

52. When P-CSCF-A receives the 200 (OK) response to the UPDATE request the P-CSCF-A performs the same 
actions as in step 20. 

53-60. 180 (Ringing) response (UE-B to UE-A via P-CSCF-B, IBCF-4, IBCF-3, intermediate IMS CN 
subsystem entities, IBCF-2, IBCF-1 and P-CSCF-A). 

The 1 80 (Ringing) response does not contain SDP hence no OMR specific action is required. 

61-68. 200 (OK) response to the INVITE request (UE-B to UE-A via P-CSCF-B, IBCF-4, IBCF-3, 
intermediated IMS CN subsystem, IBCF-2, IBCF-1 and P-CSCF-A). 

The User B accepts the call and the UE-B sends a 200 (OK) response to the INVITE request. The response 
contains no SDP. 

The IBCF-1 and IBCF-2 releases the MR not used in the call. 

69-76. ACK request (UE-A to UE-B via P-CSCF-A, IBCF-1, IBCF-2, intermediated IMS CN subsystem, 
IBCF-3, IBCF-4 and P-CSCF-B). 

The UE-B acknowledges the receiption of the 200 (OK) response by means of a 200 (OK) response. 
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